Preamble
PostgreSQL SELECT statement is used to extract records from one or more tables into PostgreSQL.
In its simplest form, the syntax for the SELECT statement in PostgreSQL
SELECT_id
FROM tabs
[WHERE conds];
The full syntax for the SELECT PostgreSQL statement
SELECT [ ALL | DISTINCT | DISTINCT ON (distinct_expressions_id) ]
expressions_id
FROM tabs
[WHERE conds]
[GROUP BY_id]
[HAVING cond]
[ORDER BY expression [ ASC | DESC | USING operator ] [ NULLS FIRST | NULLS LAST ]]
[LIMIT [ number_rows | ALL]
[OFFSET offset_value [ ROW | ROWS ]]
[FETCH { FIRST | NEXT } [ fetch_rows ] { ROW | ROWS } ONLY]
[FOR { UPDATE | SHARE } OF table [ NOWAIT ]];
Parameters and arguments of the statement
- ALL – Optional. Returns all matching strings.
- DISTINCT – Optional. Removes duplicates from the result set. Learn more about the DISTINCT operator.
- DISTINCT ON – Optional. Removes duplicates based on different_expressions. Learn more about the DISTINCT ON operator.
- expressions_id – The table or calculations you want to get. Use * if you want to select all columns.
- tabs – The tables from which you want to get the records. At least one table must be specified in the FROM statement.
- WHERE conds – Optional. The conditions that must be met for the records to be selected.
- GROUP BY_id – Optional. It collects data from several records and groups the results into one or more columns.
- HAVING cond – Optional. It is used in combination with GROUP BY to limit groups of returned rows to only those whose TRUE condition.
- ORDER BY expression_id – Optional. It is used to sort the entries in your resulting set.
- LIMIT – Optional. If LIMIT is specified, it controls the maximum number of records to extract. The maximum number of records specified by the number_rows will be returned in the resulting set. The first line returned by LIMIT will be defined as offset_value.
- FETCH – Optional. If FETCH is specified, it controls the maximum number of records to extract. At most, the maximum number of records specified by fetch_rows will be returned in the resulting set. The first line returned by FETCH will be defined as offset_value.
- FOR UPDATE – Optional. Records affected by the query are blocked from being written until the transaction is completed.
- FOR SHARE – Optional. Records affected by a query may be used by other transactions, but cannot be updated or deleted by those other transactions.
Example: select all fields from one table
Let’s see how to use PostgreSQL query SELECT to select all fields in a table.
SELECT *
FROM categories
WHERE category_id >= 2500
ORDER BY category_id ASC;
In this example of the SELECT PostgreSQL statement, we used * to specify that we want to select all fields from the category table where category_id is greater than or equal to 2500. The resulting set is sorted by category_id in ascending order.
Example: select individual fields from one table
You can also use PostgreSQL statement SELECT to select individual fields from a table, unlike all fields from a table.
For example:
SELECT category_id, category_name, comments
FROM categories
WHERE category_name = 'Hardware'
ORDER BY category_name ASC, comments DESC;
This PostgreSQL example SELECT will only return the category_id, category_name, and comments fields from the category table, where category_name is ‘Hardware’. The results are sorted by category_name in ascending order and then by comments in descending order.
Example: selecting fields from several tables
You can also use the SELECT operator of PostgreSQL to extract fields from multiple tables.
SELECT products.product_name, categories.category_name
FROM categories
INNER JOIN products
ON categories.category_id = products.category_id
ORDER BY product_name;
This PostgreSQL SELECT example connects two tables to get the resulting set, which displays the product_name and category_name fields where the category_id value matches in both the categories and product tables. The results are sorted by product_name in ascending order.
PostgreSQL: Select From | Course
About Enteros
Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of clouds, RDBMS, NoSQL, and machine learning database platforms.
The views expressed on this blog are those of the author and do not necessarily reflect the opinions of Enteros Inc. This blog may contain links to the content of third-party sites. By providing such links, Enteros Inc. does not adopt, guarantee, approve, or endorse the information, views, or products available on such sites.
Are you interested in writing for Enteros’ Blog? Please send us a pitch!
RELATED POSTS
Scaling AI Without Overspend: How Enteros Brings Financial Clarity to AI Platforms
- 22 January 2026
- Database Performance Management
Introduction Artificial intelligence is no longer experimental. Across industries, AI platforms now power core business functions—recommendation engines, fraud detection, predictive analytics, conversational interfaces, autonomous decision systems, and generative AI applications. But as AI adoption accelerates, a critical problem is emerging just as fast: AI is expensive—and most organizations don’t fully understand why. Read more”Indian Country” … Continue reading “Scaling AI Without Overspend: How Enteros Brings Financial Clarity to AI Platforms”
AI-Native Database Performance Management for Real Estate Technology Enterprises with Enteros
Introduction Real estate has rapidly evolved into a technology-driven industry. From digital property marketplaces and listing platforms to smart building systems, valuation engines, CRM platforms, and AI-powered analytics, modern real estate enterprises run on data-intensive technology stacks. At the center of this transformation lies a critical foundation: databases. Every property search, pricing update, lease transaction, … Continue reading “AI-Native Database Performance Management for Real Estate Technology Enterprises with Enteros”
Driving RevOps Efficiency Through AI-Driven Database Optimization with Enteros
- 21 January 2026
- Database Performance Management
Introduction Revenue Operations (RevOps) has become the backbone of modern digital enterprises. By aligning sales, marketing, finance, and customer success, RevOps promises predictable growth, faster decision-making, and improved customer lifetime value. Yet, for many organizations, RevOps efficiency remains elusive. The missing link is often hidden deep within the technology stack: the database layer. Every revenue … Continue reading “Driving RevOps Efficiency Through AI-Driven Database Optimization with Enteros”
How Retail Companies Can Reduce Cloud Costs Through Database Optimization with Enteros
Introduction Retail has become one of the most data-intensive industries in the digital economy. Modern retailers rely on cloud-powered platforms to support omnichannel commerce, real-time inventory visibility, personalized recommendations, dynamic pricing, loyalty programs, supply chain optimization, and customer analytics. At the center of all these capabilities sits a critical layer: databases. Retail databases process millions … Continue reading “How Retail Companies Can Reduce Cloud Costs Through Database Optimization with Enteros”