Public schema vs custom schemas in PostgreSQL - Performance Comparison
When working with PostgreSQL schemas, it's important to understand how accessing tables in different schemas affects query performance.
We want to see how the time to find and use tables changes when using the public schema versus custom schemas.
Analyze the time complexity of querying a table in different schemas.
-- Query from public schema
SELECT * FROM public.users WHERE id = 10;
-- Query from custom schema
SELECT * FROM custom_schema.users WHERE id = 10;
-- Setting search path to custom schema
SET search_path TO custom_schema;
SELECT * FROM users WHERE id = 10;
This code shows queries accessing the same table name in different schemas and using search_path to simplify access.
Look at what happens when PostgreSQL finds the table to run the query.
- Primary operation: Schema lookup to find the table definition.
- How many times: Once per query execution, but can repeat if multiple tables or schema changes occur.
Finding a table in a schema is like looking up a name in a small list.
| Number of Schemas | Approx. Lookup Steps |
|---|---|
| 1 (public only) | 1 step |
| 5 schemas | Up to 5 steps |
| 100 schemas | Up to 100 steps |
Pattern observation: The more schemas in the search path, the longer it may take to find the table, growing roughly linearly with the number of schemas.
Time Complexity: O(n)
This means the time to find a table grows linearly with the number of schemas checked in the search path.
[X] Wrong: "Using the public schema is always faster than custom schemas because it's the default."
[OK] Correct: The speed depends on how many schemas PostgreSQL searches before finding the table, not just which schema it is.
Understanding how schema search paths affect query time helps you design databases that are easy to maintain and perform well.
"What if we add an index on the schema name lookup? How would that change the time complexity of finding tables?"
Practice
public schema in PostgreSQL?Solution
Step 1: Understand the default schema concept
In PostgreSQL, thepublicschema is created by default in every new database.Step 2: Identify the role of the public schema
When you create tables or other objects without specifying a schema, they go into thepublicschema automatically.Final Answer:
It is the default schema where database objects are created if no schema is specified. -> Option BQuick Check:
Default schema = public [OK]
- Thinking public schema is read-only
- Assuming public schema is for system tables only
- Believing public schema encrypts data automatically
sales in PostgreSQL?Solution
Step 1: Recall the SQL syntax for creating schemas
The correct SQL command to create a schema isCREATE SCHEMA schema_name;.Step 2: Check each option
CREATE SCHEMA sales; uses the correct syntax. MAKE SCHEMA sales;, CREATE DATABASE sales;, and NEW SCHEMA sales; are invalid SQL commands for creating schemas.Final Answer:
CREATE SCHEMA sales; -> Option AQuick Check:
CREATE SCHEMA = create new schema [OK]
- Using CREATE DATABASE instead of CREATE SCHEMA
- Using non-existent commands like NEW SCHEMA or MAKE SCHEMA
- Forgetting the semicolon at the end
CREATE SCHEMA marketing; CREATE TABLE marketing.campaigns (id SERIAL PRIMARY KEY, name TEXT); SET search_path TO marketing, public; SELECT * FROM campaigns;
What will be the result of the SELECT query?
Solution
Step 1: Understand search_path usage
Thesearch_pathis set to look first inmarketingschema, thenpublic.Step 2: Identify which table is found
The tablecampaignsexists inmarketingschema, so the query finds and returns data frommarketing.campaigns.Final Answer:
It will return all rows from the marketing.campaigns table. -> Option CQuick Check:
search_path order finds marketing first [OK]
- Assuming table must be schema-qualified always
- Thinking query errors without schema prefix
- Ignoring search_path order
SELECT * FROM sales.orders;
But get the error:
ERROR: schema "sales" does not exist.What is the most likely cause?
Solution
Step 1: Analyze the error message
The error says the schema "sales" does not exist, meaning PostgreSQL cannot find that schema.Step 2: Identify the cause
This usually means the schema was never created or was dropped, so the database has no knowledge of it.Final Answer:
The sales schema has not been created yet. -> Option AQuick Check:
Schema missing causes this error [OK]
- Assuming search_path affects schema existence errors
- Thinking table absence causes schema not found error
- Trying to fix with quotes unnecessarily
hr and finance. You create tables with the same name employees in both schemas. How can you write a query to select all employees from the finance schema without changing the search_path?Solution
Step 1: Understand schema-qualified table names
When tables have the same name in different schemas, you can specify the schema explicitly before the table name.Step 2: Identify the correct query
SELECT * FROM finance.employees; usesfinance.employeeswhich directly accesses the table in the finance schema without changing search_path.Final Answer:
SELECT * FROM finance.employees; -> Option DQuick Check:
Schema-qualified names access tables directly [OK]
- Trying to filter by schema column which doesn't exist
- Changing search_path unnecessarily
- Assuming public schema contains all tables
Ready to prove it?
Pass the test and this pattern moves unknown
