PostgreSQL Scripts for Database Administration on Postgres Scripts

Monitor Last VACUUM Runs with pg_stat_user_tables

Sun, 12 Jul 2026 00:00:00 +0000

Monitor Last VACUUM Runs with pg_stat_user_tables

A table's dead tuple count climbing while last_autovacuum stays weeks old isn't noise — it's the clearest sign autovacuum is falling behind, and pg_stat_user_tables is where that gap becomes visible in a single query, without tailing logs or guessing at a schedule.

Purpose and Overview

pg_stat_user_tables is a cumulative statistics view: one row per user table, holding scan counts, tuple counts, and maintenance timestamps that accumulate for the life of the server (or since the last pg_stat_reset()). The view carries columns for two distinct maintenance operations in the same row — VACUUM and ANALYZE — but they trigger independently, run on different thresholds, and carry different operational risk. Conflating them in a single audit muddies the signal.

Query PostgreSQL Tablespace Info with pg_tablespace

Fri, 03 Jul 2026 00:00:00 +0000

Query PostgreSQL Tablespace Info with pg_tablespace

What tablespaces exist in this cluster, who owns each one, and where do their files actually live on disk? pg_tablespace answers all three: it holds one row per tablespace with the owner OID, access control list, storage options, and — via pg_tablespace_location() — the on-disk path, all readable from a single catalog query without parsing configuration files or tracing symlinks by hand.

Purpose and Overview

Tablespaces are PostgreSQL's mechanism for controlling where data files land on disk. Every cluster starts with two built-in spaces: pg_default, which holds user tables and indexes, and pg_global, which holds the cluster-wide system catalogs. Additional tablespaces appear when a DBA runs CREATE TABLESPACE pointing at a different mount point — typically a faster SSD volume for a hot OLTP schema, a slower spinning disk for archive data, or a dedicated volume to isolate write-amplification from MVCC-heavy tables.

List PostgreSQL Functions with pg_proc

Thu, 02 Jul 2026 00:00:00 +0000

List PostgreSQL Functions with pg_proc

Where information_schema.routines delivers a SQL-standard view of functions and procedures — portable across databases but deliberately incomplete — pg_proc gives the full PostgreSQL catalog row: language, source code, argument modes, cost estimates, and the prokind flag that distinguishes regular functions from aggregates, window functions, and stored procedures in a single query.

Purpose and Overview

Every function, procedure, aggregate, and window function created in a PostgreSQL database has a row in pg_proc. The catalog stores the complete definition: the function name, the schema it lives in, the language it was written in, the source text, the argument list with modes and default values, the return type, and planner hints such as estimated cost and expected row count. It is the authoritative source for everything a DBA or developer needs to audit the stored-code layer of a database.

Inspect PostgreSQL Sequences with the pg_sequences View

Sat, 20 Jun 2026 00:00:00 +0000

Inspect PostgreSQL Sequences with the pg_sequences View

pg_sequences is the catalog-backed view that exposes every sequence in the current database in one readable row each — start_value, min_value, max_value, increment_by, cache_size, cycle, and the all-important last_value. It turns a scattered set of per-sequence currval() lookups into a single audit query.

Purpose and Overview

Sequences are easy to create and easy to forget. Every SERIAL or GENERATED AS IDENTITY column quietly relies on a sequence object to hand out the next number, and most of the time nobody looks at one until an INSERT fails with a "nextval: reached maximum value" error. By then the table is blocked for new rows and the fix has to happen under pressure.

Track Two-Phase Commit State with pg_prepared_xacts

Fri, 19 Jun 2026 00:00:00 +0000

Track Two-Phase Commit State with pg_prepared_xacts

A prepared transaction that never gets committed or rolled back is one of the quieter ways a PostgreSQL database degrades. It keeps holding locks, it pins the transaction-ID horizon so VACUUM cannot reclaim dead rows, and nothing in normal monitoring screams about it. Left long enough it can drive the cluster toward a transaction-ID wraparound shutdown.

Purpose and Overview

Two-phase commit (2PC) splits a commit into two steps so an external coordinator can commit the same logical transaction across several resources atomically. In PostgreSQL the first step is PREPARE TRANSACTION 'gid', which writes the transaction's state to disk and assigns it a global identifier. The transaction is now durable but undecided: it survives a server restart and waits for a later COMMIT PREPARED 'gid' or ROLLBACK PREPARED 'gid', possibly from a different session.

Monitor PostgreSQL ANALYZE Progress with pg_stat_progress_analyze

Thu, 18 Jun 2026 00:00:00 +0000

Monitor PostgreSQL ANALYZE Progress with pg_stat_progress_analyze

Running ANALYZE on a multi-hundred-gigabyte table and wondering whether it is halfway done or barely started is a common operational question with, until recently, no good answer. pg_stat_progress_analyze answers it: a live view that reports the current phase of every running ANALYZE and how many sample blocks it has scanned.

Purpose and Overview

ANALYZE collects column statistics that the query planner depends on to choose good plans. On a small table it finishes in milliseconds and nobody thinks about it. On a very large table, or one with many child partitions, it can run for minutes, and during that window two questions matter: is it actually making progress, and how long until it is done. A manual ANALYZE issued before a big read-heavy job, or an autovacuum-launched analyze competing for I/O, both raise the same need for visibility.

Query PostgreSQL I/O Statistics with pg_stat_io

Wed, 17 Jun 2026 00:00:00 +0000

Query PostgreSQL I/O Statistics with pg_stat_io

An I/O spike that nobody can attribute is a frustrating thing to chase. Was it autovacuum, a checkpoint, a bulk load, or ordinary client queries? Before PostgreSQL 16 the answer required stitching together several partial views; pg_stat_io gives a single cluster-wide breakdown of reads, writes, extends, and cache activity by backend type and I/O context.

Purpose and Overview

pg_stat_io is a cumulative statistics view that decomposes the server's block I/O along two axes at once. The first is backend_type — client backends, autovacuum workers, the background writer, the checkpointer, and so on. The second is context — normal activity, vacuum, bulkread, and bulkwrite. The cross-product of those two axes is what makes the view powerful: it does not just say "the server did 40 GB of reads," it says which subsystem did them and under what kind of operation.

TRUNCATE vs DELETE vs DROP: Remove Rows Fast in PostgreSQL

Tue, 16 Jun 2026 00:00:00 +0000

TRUNCATE vs DELETE vs DROP: Remove Rows Fast in PostgreSQL

Where DELETE removes rows one logical version at a time and leaves the cleanup to vacuum, TRUNCATE discards an entire table's contents almost instantly and reclaims the space immediately, and DROP removes the table itself. Picking the wrong one for "empty this table" is a common cause of surprise WAL floods and runaway bloat.

Purpose and Overview

"Just clear the table" sounds like one operation, but PostgreSQL offers three commands with very different costs. The reason the choice matters comes down to how PostgreSQL stores data. Under multiversion concurrency control (MVCC), a DELETE does not physically remove a row — it marks each row version as deleted by stamping its xmax, leaving a dead tuple behind. Those dead tuples occupy space until vacuum reclaims them, and on a full-table delete that means writing one WAL record per row and generating dead tuples across the entire table.

timestamptz and tzdata: Avoid Shifted PostgreSQL Timestamps

Mon, 15 Jun 2026 00:00:00 +0000

timestamptz and tzdata: Avoid Shifted PostgreSQL Timestamps

PostgreSQL stores every timestamptz value as UTC and converts it to the session's time zone only at display time. That design is correct and elegant — until a tzdata update changes the offset rules for a region, at which point timestamps inserted under the old rules can render at a different local time than the day they were recorded.

Purpose and Overview

timestamp with time zone, almost always written timestamptz, is the type most applications should use for points in time. The name is slightly misleading: the column does not store a time zone. It stores a single absolute instant as UTC. When you insert a value with an explicit offset, PostgreSQL converts it to UTC for storage and discards the original zone; when you read it back, it converts from UTC to whatever the session's TimeZone parameter is set to. Two clients in different zones see the same instant rendered in their own local time, and that is exactly the behavior you want.

Back Up All PostgreSQL Databases with pg_dumpall

Tue, 09 Jun 2026 00:00:00 +0000

Back Up All PostgreSQL Databases with pg_dumpall

Before a major-version upgrade or a disaster-recovery rehearsal, a DBA needs a single artifact that captures the whole cluster: every database, plus the global objects that live outside any one database. pg_dumpall produces exactly that — one plain-SQL script that recreates all databases together with the roles, tablespaces, and grants that pg_dump on its own leaves behind.

Purpose and Overview

pg_dump backs up a single database. It does a thorough job inside that database, but it does not capture cluster-wide objects. Roles (users and groups), role memberships, tablespace definitions, and the privileges attached to them are stored once per cluster, not once per database. Restore a pg_dump file into a fresh server and the owners and grant statements refer to roles that do not exist yet.

PostgreSQL Advisory Locks with pg_advisory_lock

Mon, 08 Jun 2026 00:00:00 +0000

PostgreSQL Advisory Locks with pg_advisory_lock

Two scheduled jobs fire at the same minute and both try to process the same nightly batch. Nothing in the data stops them — there is no single row to lock, because the work has not produced rows yet. Row and table locks are the wrong tool here. What you want is a named lock that the application agrees to respect, held for as long as the job runs. PostgreSQL provides this with advisory locks through pg_advisory_lock and its companion functions.

List All PostgreSQL Triggers with Their State

Sun, 07 Jun 2026 00:00:00 +0000

List All PostgreSQL Triggers with Their State

A disabled trigger is invisible until something it should have done goes missing. The audit row that never got written, the derived column that stopped updating, the constraint check that silently stopped firing — each traces back to a trigger left in the disabled state after a bulk load or a restore. Listing files in \d does not show this, but pg_trigger.tgenabled does: one query returns every trigger across the database together with whether it actually fires.

PostgreSQL Column-Level Permissions Audit Query

Sat, 06 Jun 2026 00:00:00 +0000

PostgreSQL Column-Level Permissions Audit Query

Which roles can read which columns? Table-level grants are easy to list, but they hide a finer layer of access. A role denied SELECT on a table can still hold SELECT on two of its columns, and that is exactly where personal data quietly stays reachable after a wider grant is revoked. The information_schema.column_privileges view answers the column-level question directly: every grantee, every column, every privilege, in one query.

List PostgreSQL Wait Events with the pg_wait_events View

Mon, 25 May 2026 00:00:00 +0000

List PostgreSQL Wait Events with the pg_wait_events View

PostgreSQL 17 added pg_wait_events, a system view that enumerates every wait event the running server can record. Prior to 17 the same information lived only in the documentation — no in-database way to confirm a wait name or attach a description to it. The view is read-only, three columns wide, and exactly the lookup table a monitoring dashboard wants alongside pg_stat_activity.

Purpose and Overview

Wait-event monitoring is one of the highest-signal PostgreSQL observability surfaces. When a backend is not actively running CPU work, PostgreSQL records why it is paused in two columns of pg_stat_activity: wait_event_type (the broad category) and wait_event (the specific reason). Tracking which waits dominate over time tells a DBA whether a workload is bound by lock contention, I/O latency, internal lightweight-lock contention, or client-side stalls — a sharper diagnostic frame than CPU utilization or query duration alone.

Identify Running PostgreSQL Autovacuum Worker Sessions

Sun, 24 May 2026 00:00:00 +0000

Identify Running PostgreSQL Autovacuum Worker Sessions

Autovacuum lag is a slow accumulation. Every UPDATE rewrites the row and creates a new HOT chain, the launcher falls behind during write spikes, and over weeks a busy OLTP cluster ends up with three workers stuck on a handful of huge tables while smaller ones wait their turn. Knowing which tables each worker is processing — and how far along — is the first step in deciding whether to wait it out, raise autovacuum_max_workers, or run a manual VACUUM.

Monitor PostgreSQL WAL Archiver Status with pg_stat_archiver

Sat, 23 May 2026 00:00:00 +0000

Monitor PostgreSQL WAL Archiver Status with pg_stat_archiver

pg_stat_archiver is the canonical place to check whether PostgreSQL's continuous archiving is keeping up — a single-row view that exposes last_archived_wal, last_failed_wal, and the rolling failure count without parsing log files. On a healthy cluster the row is uninteresting; on a stalled cluster it is the difference between catching a problem in minutes and finding a full WAL volume on Saturday night.

Purpose and Overview

A PostgreSQL cluster configured for continuous archiving runs the archive_command (or archive_library on PostgreSQL 15+) once per finalized WAL segment. The command's job is to copy the segment somewhere durable — typically S3, NFS, or a backup server — so the WAL stream can later feed point-in-time recovery (PITR) or warm-standby replay. When the archive command fails (target unreachable, disk full, permission revoked, network partition), PostgreSQL retries continuously, pg_wal accumulates segments, and the cluster eventually fills its WAL volume. At that point writes stop until space is freed.

Monitor PostgreSQL Replication Lag with pg_stat_replication

Fri, 22 May 2026 00:00:00 +0000

Monitor PostgreSQL Replication Lag with pg_stat_replication

A standby lagging more than a few seconds is rarely a transient hiccup — it is a query backlog on the standby, a network ceiling between the nodes, a misconfigured hot_standby_feedback, or a single-threaded apply storm. pg_stat_replication joined to pg_wal_lsn_diff() exposes each replica's byte lag and time lag in one row, on the primary, no SSH required.

Purpose and Overview

PostgreSQL streaming replication is asynchronous by default. The primary commits a transaction, writes the WAL record locally, the WAL sender forwards it to the standby, the standby writes it to its own WAL, flushes the WAL to disk, and finally replays it into the data files. Each stage runs on a separate thread of execution, and each stage has its own latency. Under load they diverge: write may be near-instant, flush a few milliseconds, and replay seconds or minutes behind on a busy standby.

Tune PostgreSQL Background Writer with pg_stat_bgwriter

Thu, 21 May 2026 00:00:00 +0000

Tune PostgreSQL Background Writer with pg_stat_bgwriter

Where pg_stat_statements does query-level aggregation and pgBadger does after-the-fact log analysis, pg_stat_bgwriter operates at the buffer-cache layer — answering whether the bgwriter and checkpointer are keeping shared_buffers clean enough that foreground queries never have to pay for a write inline. On a healthy OLTP cluster the answer is almost always yes; on a struggling one the counters say which knob to turn first.

Purpose and Overview

When a PostgreSQL backend needs a clean buffer in shared_buffers and none is available, something has to flush a dirty page back to disk before the backend can continue. Three subsystems share that workload. The checkpointer flushes every dirty buffer at checkpoint time, spreading the writes over checkpoint_completion_target × checkpoint_timeout to avoid I/O spikes. The background writer ("bgwriter") runs continuously, sweeping a small window of the LRU list each bgwriter_delay and writing out dirty buffers to keep a runway of clean buffers available. And when neither of those has kept up, the user-facing backend writes the buffer itself — inline, on the critical path of the query.

Monitor PostgreSQL Wait Events Using pg_stat_activity

Sun, 17 May 2026 00:00:00 +0000

Understanding PostgreSQL Wait Events for Performance Analysis

Every active PostgreSQL backend is either executing work or waiting. When a session waits, PostgreSQL records the reason in pg_stat_activity using two columns: wait_event_type and wait_event. Aggregating these across all sessions gives a clear picture of where your database is spending idle time — and what is holding it back.

Common wait event types include Lock (heavyweight locks between transactions), LWLock (internal lightweight locks), IO (disk reads and writes), IPC (inter-process communication), and Client (waiting on application input). A cluster dominated by IO waits may need larger shared_buffers; a cluster dominated by Lock waits has contention between transactions that needs investigation at the query level.

Monitor PostgreSQL Vacuum Progress with pg_stat_progress_vacuum

Sat, 16 May 2026 00:00:00 +0000

Tracking Active Vacuum and Autovacuum Workers in PostgreSQL

PostgreSQL vacuum is the maintenance process that removes dead tuples left behind by updates and deletes, reclaims storage, and prevents transaction ID wraparound. On active databases, autovacuum runs continuously in the background, but knowing whether it is actually making progress — and on which tables — requires querying the pg_stat_progress_vacuum view.

Introduced in PostgreSQL 9.6, pg_stat_progress_vacuum exposes one row per active vacuum worker, including both manual VACUUM commands and autovacuum background workers. The view shows the current phase, block counts scanned and vacuumed, and dead tuple statistics. This is the primary tool for answering the operational question: is vacuum keeping up, and if not, where is it stuck?

PostgreSQL Physical Backup Guide with pg_basebackup

Fri, 15 May 2026 00:00:00 +0000

PostgreSQL Physical Backups with pg_basebackup

pg_basebackup takes a physical, binary-level snapshot of a running PostgreSQL cluster. Unlike pg_dump, which produces a logical export of one database at a time, pg_basebackup captures the entire data directory — all databases, configuration files, and enough WAL to make the backup consistent. The result is suitable for two critical operations: initializing a streaming replication standby, and serving as the base for point-in-time recovery (PITR).

Monitor PostgreSQL Table Cache Hit Ratio with SQL

Thu, 14 May 2026 00:00:00 +0000

Measuring PostgreSQL Table Cache Efficiency with pg_statio_user_tables

PostgreSQL keeps frequently accessed data pages in shared_buffers to avoid hitting disk. When a backend reads a data block, PostgreSQL first checks shared_buffers; if the block is there, it counts as a heap hit. If it is not, PostgreSQL reads from disk and counts it as a heap read. The ratio of hits to total reads — the table cache hit ratio — is a primary indicator of how well your shared_buffers setting matches your working data set.

PostgreSQL Replica Identity for Logical Replication

Mon, 20 Apr 2026 00:00:00 +0000

Check Replica Identity Settings in PostgreSQL

Logical replication in PostgreSQL requires each replicated table to have a replica identity. The replica identity tells PostgreSQL which columns to include in the WAL record for UPDATE and DELETE operations so the subscriber can identify the row being changed.

If replica identity is misconfigured, updates and deletes either fail on the subscriber or replicate incorrectly. This query shows the current replica identity setting for every table in your database so you can audit and fix any gaps before enabling a publication.

List Collations in Your PostgreSQL Database

Sun, 19 Apr 2026 00:00:00 +0000

How to List Collations Available in PostgreSQL

A collation defines the rules for sorting and comparing text. It controls how ORDER BY handles strings, whether a and A compare as equal, and how accented characters rank relative to unaccented ones. Every text column in PostgreSQL has a collation, either inherited from the database default or set explicitly on the column or expression.

Knowing which collations are available is useful when creating columns that need locale-specific sorting, diagnosing unexpected sort order in query results, or migrating data between databases with different locale settings.

List Installed Extensions in PostgreSQL

Sat, 18 Apr 2026 00:00:00 +0000

How to List Installed Extensions in PostgreSQL

PostgreSQL extensions package additional functionality — data types, functions, operators, and index methods — that can be installed into a database with CREATE EXTENSION. Common examples include pg_stat_statements for query performance tracking, uuid-ossp for UUID generation, postgis for geographic data, and pg_trgm for fuzzy text search.

Before modifying a database or diagnosing unexpected behavior, it is useful to know exactly which extensions are installed, which versions are running, and which schema their objects live in.

List PostgreSQL Roles and Their Privileges

Fri, 17 Apr 2026 00:00:00 +0000

How to List PostgreSQL Roles and Privileges

PostgreSQL uses roles for both users and groups. A role with the LOGIN attribute is a user account. A role without LOGIN is typically a group role used to collect privileges that are then granted to login roles. Understanding which roles exist, what privileges they have, and which roles belong to which groups is a fundamental security audit task.

This article shows SQL queries to list all roles, their key attributes, and role membership.

Scrubbing Email PII in PostgreSQL for GDPR Compliance

Fri, 17 Apr 2026 00:00:00 +0000

Scrubbing Email PII from Your PostgreSQL Database

When you copy a production database to a development or test environment, you must remove or anonymize personally identifiable information (PII). Email addresses are among the most common PII fields that need to be scrubbed. Leaving real email addresses in non-production databases creates compliance risk under GDPR, CCPA, and similar regulations.

PostgreSQL makes it straightforward to build a reusable scrubbing solution using a PL/pgSQL function for single-row replacement and a stored procedure for batch processing large tables.

Audit Single vs Multi-Column Indexes in PostgreSQL

Thu, 16 Apr 2026 00:00:00 +0000

Audit Single vs Multi-Column Indexes in PostgreSQL

Not all indexes are created equal. A single-column index covers one column and is simple to reason about. A multi-column (composite) index covers two or more columns and can serve a wider range of queries — but only when the leading columns match the query filter.

As a database grows, it is easy to accumulate indexes without a clear picture of what type each table has. This query counts single-column and multi-column indexes per table so you can spot tables that may be over-indexed, poorly indexed, or missing composite indexes altogether.

pg_stat_database — Query PostgreSQL Database Statistics

Wed, 15 Apr 2026 00:00:00 +0000

Monitor PostgreSQL Databases with pg_stat_database

PostgreSQL tracks activity at the database level in the pg_stat_database view. Every database on the server has a row, and each row contains counters for commits, rollbacks, cache hits, disk reads, deadlocks, temp file usage, and more. This is one of the first places to look when you need a quick health check across all databases.

A simple SELECT * returns everything, but the view has over 30 columns. The query below selects the most actionable columns and formats them for easy reading.

Cancel vs Terminate PostgreSQL Backends Explained

Tue, 14 Apr 2026 00:00:00 +0000

Cancel vs Terminate PostgreSQL Backends: What Every DBA Should Know

PostgreSQL gives you two tools for dealing with problem backends: pg_cancel_backend() and pg_terminate_backend(). They sound similar but behave very differently. Using the wrong one can disrupt users unnecessarily, or leave a problematic connection in place when you needed it gone entirely.

This guide explains both functions, when to use each, and how to identify the right PIDs to target.

Sample Code

Cancel a running query (leaves the connection open):

List All Schemas in Your PostgreSQL Database

Mon, 13 Apr 2026 00:00:00 +0000

How to List All Schemas in a PostgreSQL Database

A PostgreSQL database can contain multiple schemas. Schemas act as namespaces that group tables, views, functions, and other objects. In a fresh database you will find public and a set of system schemas. In a larger application database you may find dozens of application schemas, one per tenant, or schemas that separate different parts of the codebase.

Knowing which schemas exist and who owns them is a basic but essential administrative task. These queries give you that information quickly.

List PostgreSQL Partitioned Tables with SQL

Thu, 09 Apr 2026 00:00:00 +0000

How to List PostgreSQL Partitioned Tables

PostgreSQL table partitioning splits a large table into smaller physical pieces called child partitions. This improves query performance and simplifies data lifecycle management. But as a DBA, you need a quick way to see which tables in your database use partitioning — and which do not.

This SQL query reads directly from the PostgreSQL system catalogs to list every table in your database, labeling each as a partitioned table or an ordinary table, while excluding system schemas and child partition tables.

Find PostgreSQL Tables Without a Primary Key

Wed, 08 Apr 2026 00:00:00 +0000

How to Find PostgreSQL Tables Without a Primary Key

A missing primary key is one of the most common and damaging database design oversights. Without a primary key, PostgreSQL has no reliable way to uniquely identify a row. This causes problems with logical replication, ORM frameworks, and application-level updates or deletes that may silently affect the wrong rows.

This SQL query scans information_schema to find every user table in your database that has no primary key or unique key constraint. Running it regularly is a simple way to catch schema problems before they reach production.

List All Views in a PostgreSQL Database with SQL

Tue, 07 Apr 2026 00:00:00 +0000

How to List All Views in a PostgreSQL Database

Views are saved SQL queries stored in the database. A production database can accumulate dozens or hundreds of views over time — many created by developers, some by tools, and some that are no longer used. Knowing what views exist, which schema they belong to, and what they actually do is essential for documentation, auditing, and cleanup.

This SQL script queries information_schema.views to return every view in the current database, along with its schema and full SQL definition.

List PostgreSQL Enum Types and Their Values with SQL

Mon, 06 Apr 2026 00:00:00 +0000

How to List All Enum Types in a PostgreSQL Database

PostgreSQL supports user-defined enum types — a fixed ordered set of string values stored efficiently as integers. Enums are common in application schemas for columns like status, role, or priority. Once created, their allowed values are managed in the database catalog, not in application code.

Over time, a database can accumulate many enum types, some with values that no longer match what the application uses. This SQL script queries pg_type and pg_enum to list every enum type in the current database along with all of its allowed values.

List Foreign Key Constraints in PostgreSQL

Sun, 05 Apr 2026 00:00:00 +0000

List Foreign Key Constraints in PostgreSQL

Foreign key constraints enforce referential integrity between tables. They guarantee that a value in one table's column always has a matching row in another table. Knowing which foreign keys exist — and how they are defined — is essential before dropping tables, renaming columns, or loading large datasets.

This SQL query lists every foreign key in the public schema, showing the table that owns the constraint, the constraint name, and the full constraint definition including which columns it spans and which table it references.

Find Missing Indexes in PostgreSQL with SQL

Sat, 04 Apr 2026 00:00:00 +0000

How to Find Missing Indexes in PostgreSQL

A missing index means PostgreSQL reads every row in a table to find what it needs. This is called a sequential scan. For small tables, that is fine. For large tables, it is slow and wastes CPU and I/O.

PostgreSQL tracks sequential scans in the pg_stat_all_tables view. You can query this view to find tables that are being scanned too often without an index. Once you find those tables, you can add the right indexes and speed up your queries.

List PostgreSQL Object Comments with SQL

Sat, 04 Apr 2026 00:00:00 +0000

List PostgreSQL Object Comments with SQL

PostgreSQL allows you to attach plain-text comments to tables, columns, indexes, functions, and other database objects using the COMMENT ON command. These comments are stored in the system catalog and are visible in psql, pgAdmin, and any tool that reads pg_description. They are one of the most underused features for keeping a schema self-documenting.

This SQL query lists comments on every column across all tables in your database, showing the schema, table name, column name, and the comment text. It is useful for auditing schema documentation, onboarding new team members, and verifying that comments are in place before a schema handover.

Detect PostgreSQL Transaction ID Wraparound Risk

Fri, 03 Apr 2026 00:00:00 +0000

Detect PostgreSQL Transaction ID Wraparound Before It Causes Downtime

PostgreSQL assigns a transaction ID (XID) to every write transaction. These IDs are 32-bit integers, which means they can only count up to about 2 billion. When the counter gets close to the limit, PostgreSQL must freeze old transaction IDs to recycle them. If this does not happen in time, the database will refuse all new connections to protect data integrity — this is called a wraparound event, and it causes complete downtime.

Detect Soft Delete Patterns in PostgreSQL

Fri, 03 Apr 2026 00:00:00 +0000

Detecting Soft Delete Patterns in PostgreSQL

Soft deletes are a common application pattern. Instead of removing a row with a DELETE statement, the application marks it as deleted by setting a column — typically deleted_at — to a non-null timestamp. The row stays in the table forever. The application simply filters it out with a WHERE deleted_at IS NULL clause.

This pattern is useful for audit trails, undo functionality, and referential integrity. It is also a significant source of problems for PostgreSQL DBAs who do not know it is in use.

Find PostgreSQL Tables That Need VACUUM FREEZE

Thu, 02 Apr 2026 00:00:00 +0000

Find PostgreSQL Tables That Need VACUUM FREEZE

PostgreSQL uses transaction IDs (XIDs) to track which rows are visible to which transactions. Over time, these IDs age. When a table's oldest unfrozen XID gets too old, PostgreSQL triggers an aggressive autovacuum to freeze it. This is controlled by the vacuum_freeze_table_age setting (default: 150 million transactions).

If a table's XID age exceeds this limit, autovacuum will aggressively scan the entire table the next time it runs. This can cause sudden I/O spikes and slow down your database. It can also lead to transaction ID wraparound if left unmanaged.

pg_stat_user_tables — Find Insert-Only Tables in PostgreSQL

Thu, 02 Apr 2026 00:00:00 +0000

Identify Insert-Only Tables in PostgreSQL Using pg_stat_user_tables

Not all PostgreSQL tables behave the same way. Most application tables have a mix of inserts, updates, and deletes. A minority of tables receive only inserts. These append-only tables — event logs, audit trails, sensor readings, message queues — have fundamentally different storage and maintenance characteristics.

A DBA who treats an insert-only table the same as a general-purpose table will misconfigure autovacuum, miss partitioning opportunities, and misread bloat signals. The starting point is knowing which tables are insert-only. PostgreSQL tracks per-table DML counts in pg_stat_user_tables, and a simple query against that view identifies them.

Estimate PostgreSQL Table Bloat with SQL

Wed, 01 Apr 2026 00:00:00 +0000

How to Estimate Table Bloat in PostgreSQL

When you update or delete rows in PostgreSQL, the old row versions are not removed immediately. They stay in the table as dead tuples until VACUUM cleans them up. Over time, if VACUUM does not keep up, these dead rows pile up and the table grows larger than it needs to be. This is called table bloat.

Bloat wastes disk space and slows down queries because PostgreSQL has to read through more pages to find live data. This query estimates how much of each table is wasted space, so you can decide which tables need attention.

Find PostgreSQL Index Bloat and Wasted Space

Tue, 31 Mar 2026 00:00:00 +0000

How to Find Index Bloat and Wasted Space in PostgreSQL

Just like tables, PostgreSQL indexes can become bloated over time. When rows are updated or deleted, the old index entries are not removed immediately. They stay in the index as dead entries, wasting space and slowing down index scans.

B-tree indexes are the most common type in PostgreSQL and the most prone to bloat. This query estimates how much space is wasted in each B-tree index, so you can decide which ones need to be rebuilt.

Monitor PostgreSQL Index Build Progress with SQL

Mon, 30 Mar 2026 00:00:00 +0000

How to Monitor PostgreSQL Index Build Progress

Building an index on a large table can take minutes or even hours. Without progress tracking, it is hard to know if the build is almost done or barely started. PostgreSQL 12 introduced the pg_stat_progress_create_index view to fix this. It shows real-time progress for any index creation currently in progress.

This query joins that view with pg_stat_activity to give you a complete picture: how far along the build is, how long it has been running, and what phase it is in.

Monitor PostgreSQL HOT Updates and Fillfactor

Sun, 29 Mar 2026 00:00:00 +0000

How to Monitor PostgreSQL HOT Updates and Fillfactor

When PostgreSQL updates a row, it normally writes a new row version and creates a new index entry pointing to it. This is safe, but it adds overhead — especially on tables with many indexes.

HOT updates (Heap Only Tuple) are a smarter path. When a HOT update happens, PostgreSQL writes the new row version on the same data page and links it to the old version, without touching any indexes. This is faster and reduces index bloat. But HOT updates are only possible when there is free space on the same page as the old row.

Find Idle in Transaction Sessions in PostgreSQL

Sat, 28 Mar 2026 00:00:00 +0000

How to Find Idle in Transaction Sessions in PostgreSQL

An idle-in-transaction session is a database connection that has started a transaction but is not currently running a query. It is just sitting there, holding the transaction open. This is different from a regular idle connection, which has no open transaction.

Idle-in-transaction sessions are a common problem. They hold locks, block autovacuum, and prevent rows from being cleaned up. If they stay open long enough, they can cause serious performance problems — including transaction ID wraparound.

GRANT SELECT on All Tables in PostgreSQL — with Examples

Fri, 27 Mar 2026 00:00:00 +0000

Grant SELECT on All Tables in PostgreSQL

Third-party ETL connectors, BI platforms, and audit users all need read access to PostgreSQL tables — without write permissions that could corrupt production data. Granting SELECT table by table works until someone adds a new table and the connector silently skips it; ALTER DEFAULT PRIVILEGES is the statement that closes that gap, applying SELECT to every future table the moment it is created.

Kill Idle PostgreSQL Sessions with SQL

Tue, 24 Mar 2026 00:00:00 +0000

Kill Idle PostgreSQL Sessions with SQL

These PostgreSQL scripts terminate idle sessions that have been inactive for more than 15 minutes. Two variants are provided: one that targets idle sessions across all databases on the server, and one scoped to only the currently connected database.

Purpose and Overview

Idle and stale connections hold resources — memory, file descriptors, and connection slots — even when no work is being done. In environments where connection limits are tight, or where application connection poolers leak sessions, regularly cleaning up long-idle connections keeps the database healthy and connection counts under control.

Count PostgreSQL Sessions by State with SQL

Mon, 23 Mar 2026 00:00:00 +0000

Count PostgreSQL Sessions by State

This PostgreSQL query returns a count of all server sessions grouped by their current state. It gives a fast at-a-glance view of how connections are distributed across active, idle, and problematic states.

Purpose and Overview

PostgreSQL tracks the state of every backend connection in the pg_stat_activity system view. Knowing how many connections are in each state at any given moment is one of the first checks a DBA performs when diagnosing connection pressure, performance slowdowns, or application misbehavior.

PostgreSQL Miscellaneous Settings Query Guide

Sun, 22 Mar 2026 00:00:00 +0000

PostgreSQL Miscellaneous Settings Query Guide

This PostgreSQL query retrieves configuration settings that fall outside all standard category groups — including customized options, process title settings, and any settings added by extensions or custom builds. It works as a catch-all complement to the other category-specific settings queries.

Purpose and Overview

The PostgreSQL pg_settings view groups every configuration parameter into a category such as Memory, Logging, or Replication. Most settings scripts target one specific category. This script takes the opposite approach: it excludes all known categories and returns only what remains.

PostgreSQL Preset Options Settings Query Guide

Sat, 21 Mar 2026 00:00:00 +0000

PostgreSQL Preset Options Settings Query Guide

This PostgreSQL query retrieves preset option settings from the pg_settings system view. Preset options are read-only, compiled-in values that describe fundamental characteristics of the PostgreSQL installation — they cannot be changed at runtime.

Purpose and Overview

Preset options expose compile-time constants and build-time decisions that are baked into the PostgreSQL binary. Unlike tunable parameters, these values are fixed for the life of the installation and can only change by reinstalling or recompiling PostgreSQL.

PostgreSQL Query Planning Settings Query Guide

Fri, 20 Mar 2026 00:00:00 +0000

PostgreSQL Query Planning Settings Query Guide

This PostgreSQL query retrieves all query tuning and statistics collection settings from the pg_settings system view. These parameters control how the query planner selects execution strategies, estimates costs, and collects runtime statistics.

Purpose and Overview

The PostgreSQL query planner decides how to execute every SQL statement — which indexes to use, whether to hash-join or merge-join, whether to use parallel workers, and more. The settings exposed by this query directly influence those decisions.

PostgreSQL Replication Settings Query Guide

Thu, 19 Mar 2026 00:00:00 +0000

PostgreSQL Replication Settings Query Guide

This PostgreSQL query retrieves all replication-related configuration settings from the pg_settings system view. These parameters control streaming replication, logical replication, standby server behaviour, and WAL sender configuration.

Purpose and Overview

Replication is critical infrastructure for high availability and disaster recovery. Misconfigured replication settings are a common cause of replication lag, replication slot bloat, or standbys falling too far behind to catch up.

This query gives administrators a single view of every replication parameter — whether they are managing a primary server, a hot standby, or logical replication subscribers.

PostgreSQL Resource Settings Query Guide

Wed, 18 Mar 2026 00:00:00 +0000

PostgreSQL Resource Settings Query Guide

This PostgreSQL query retrieves all resource usage configuration settings from the pg_settings system view. Resource settings control how PostgreSQL allocates memory, disk, and CPU resources across queries, background processes, and maintenance operations.

Purpose and Overview

Resource settings are among the most impactful configuration parameters for PostgreSQL performance. Allocating too little memory leads to excessive disk I/O; allocating too much can cause out-of-memory errors on the host. This query surfaces all resource-related parameters so administrators can audit and tune them in one place.

log_parser_stats, log_planner_stats, log_executor_stats — PostgreSQL

Tue, 17 Mar 2026 00:00:00 +0000

PostgreSQL Statistics Settings Query Guide

This PostgreSQL query retrieves all statistics collection configuration settings from the pg_settings system view. These parameters control what runtime data PostgreSQL collects about query execution, table activity, and performance, feeding into the pg_stat_* monitoring views.

Purpose and Overview

PostgreSQL's statistics collector gathers data about database activity and makes it available through system views like pg_stat_activity, pg_stat_user_tables, and pg_stat_statements. If the underlying collection settings are disabled, those views return incomplete or empty data.

PostgreSQL SSL Settings Query Guide

Tue, 17 Mar 2026 00:00:00 +0000

PostgreSQL SSL Settings Query Guide

This PostgreSQL query retrieves all SSL and TLS configuration settings from the pg_settings system view. It surfaces whether SSL is enabled, which certificates and keys are in use, what cipher suites are allowed, and all other SSL-related parameters.

Purpose and Overview

Encrypting connections to PostgreSQL with SSL/TLS is a baseline security requirement for any server that handles sensitive data or accepts connections over a network. This query gives administrators a fast way to audit the current SSL configuration without reading postgresql.conf directly.

PostgreSQL WAL Settings Query Guide

Mon, 16 Mar 2026 00:00:00 +0000

PostgreSQL WAL Settings Query Guide

This PostgreSQL query retrieves all Write-Ahead Log (WAL) configuration settings from the pg_settings system view. WAL settings control durability, crash recovery, checkpointing, archiving, and replication log generation.

Purpose and Overview

The Write-Ahead Log is the foundation of PostgreSQL's durability guarantee. Every data change is written to WAL before it is applied to the data files, ensuring that committed transactions survive a crash. WAL settings also control whether enough log is generated for streaming replication and point-in-time recovery.

List PostgreSQL Tables by Size with SQL

Sun, 15 Mar 2026 00:00:00 +0000

List PostgreSQL Tables by Size with SQL

This PostgreSQL query lists all tables in the current database sorted by their total size, largest first. It uses pg_total_relation_size() to include the table data, indexes, TOAST storage, and free space map in the size calculation.

Purpose and Overview

Disk space pressure is a common operational concern in any growing database. Knowing which tables consume the most space allows administrators to prioritise archiving, partitioning, or compression efforts. It also helps explain sudden disk growth when a particular table has expanded unexpectedly.

PostgreSQL Table Row Count Estimates with SQL

Sat, 14 Mar 2026 00:00:00 +0000

PostgreSQL Table Row Count Estimates with SQL

This PostgreSQL query returns estimated row counts for all user tables, sorted by the largest tables first. It reads from the statistics collector rather than scanning the tables, making it near-instant even on tables with billions of rows.

Purpose and Overview

Counting rows with SELECT COUNT(*) FROM table requires a full sequential scan of the table — on large tables this can run for minutes and generate significant I/O load. PostgreSQL's statistics collector maintains a continuously updated row estimate for every table in pg_stat_user_tables. This estimate is fast to read and accurate enough for most operational purposes.

Monitor PostgreSQL Memory Settings with pg_settings

Wed, 10 Sep 2025 00:00:00 +0000

PostgreSQL Memory Settings Query: Monitor Database Memory Configuration

This PostgreSQL query helps database administrators monitor and analyze memory-related configuration settings in their database instance. By querying the pg_settings system catalog view, you can quickly identify current memory parameters, their values, and restart requirements.

Query Breakdown

The query used:

 1SELECT
 2 name,
 3 setting,
 4 -- category,
 5 vartype,
 6 short_desc,
 7 -- enumvals,
 8 source,
 9 min_val,
10 max_val,
11 boot_val,
12 reset_val,
13 -- not available on PostgreSQL < 9.5
14 pending_restart
15FROM
16 pg_settings
17WHERE
18 -- Resource Usage / Memory
19 category ILIKE '%Memory%';

Purpose

This query serves multiple administrative purposes for PostgreSQL database management. It retrieves comprehensive information about memory-related configuration parameters, helping administrators understand current memory allocation, identify optimization opportunities, and plan configuration changes that may require database restarts.

PostgreSQL Logging Configuration Query via pg_settings

Tue, 09 Sep 2025 00:00:00 +0000

PostgreSQL Logging Configuration Query - Monitor Database Settings

This PostgreSQL query provides database administrators with essential insights into logging configuration parameters by querying the pg_settings system view. The query specifically targets logging-related settings while filtering out WAL (Write-Ahead Logging) configurations to focus purely on database logging parameters.

Query Breakdown

The provided PostgreSQL code queries the system configuration settings:

 1SELECT
 2 name,
 3 setting,
 4 -- category,
 5 vartype,
 6 short_desc,
 7 -- enumvals,
 8 source,
 9 min_val,
10 max_val,
11 boot_val,
12 reset_val,
13 -- not available on PostgreSQL < 9.5
14 pending_restart
15FROM
16 pg_settings
17WHERE
18 -- Reporting and Logging / What to Log
19 -- broader '%Log%' pulls in WAL settings which we don't want here
20 category ILIKE '%Logging%';

Purpose and Functionality

This query serves as a diagnostic tool for PostgreSQL database administrators to examine current logging configurations. It extracts critical information about how the database handles log generation, rotation, and output formatting.

PostgreSQL Lock Management Settings via pg_settings

Mon, 08 Sep 2025 00:00:00 +0000

PostgreSQL Lock Management Settings Query Guide accessing system table pg_settings

PostgreSQL's lock management system is crucial for maintaining data consistency and preventing conflicts in concurrent database operations. This guide demonstrates how to query and analyze lock-related configuration settings using the pg_settings system catalog.

Query Breakdown

The following PostgreSQL query retrieves all configuration settings related to lock management:

 1SELECT
 2 name,
 3 setting,
 4 -- category,
 5 vartype,
 6 short_desc,
 7 -- enumvals,
 8 source,
 9 min_val,
10 max_val,
11 boot_val,
12 reset_val,
13 -- not available on PostgreSQL < 9.5
14 pending_restart
15FROM
16 pg_settings
17WHERE
18 -- Lock Management
19 category ILIKE '%Lock%';

Purpose and Key Benefits

This query serves multiple purposes for database administrators and developers. It provides comprehensive information about PostgreSQL's lock management configuration, enabling you to understand current settings, identify potential performance bottlenecks, and optimize database behavior for concurrent operations.

PostgreSQL File Location Settings Query via pg_settings

Sun, 07 Sep 2025 00:00:00 +0000

PostgreSQL File Location Settings Query Guide

This PostgreSQL query helps database administrators examine file location configuration settings by querying the pg_settings system view. It retrieves essential information about where PostgreSQL stores its files and directories.

Purpose and Overview

The query targets PostgreSQL's file location settings to help administrators understand where the database stores critical files like data directories, configuration files, and log files. This information is vital for backup procedures, maintenance tasks, and system monitoring.

PostgreSQL Error Handling Settings via pg_settings

Sat, 06 Sep 2025 00:00:00 +0000

PostgreSQL Error Handling Settings Query Guide using pg_settings

PostgreSQL's pg_settings system view provides comprehensive information about database configuration parameters, particularly those related to error handling and logging. This query helps database administrators monitor and analyze error-related settings effectively.

Query Breakdown

Original Query:

 1SELECT
 2 name,
 3 setting,
 4 -- category,
 5 vartype,
 6 short_desc,
 7 -- enumvals,
 8 source,
 9 min_val,
10 max_val,
11 boot_val,
12 reset_val,
13 -- not available on PostgreSQL < 9.5
14 pending_restart
15FROM
16 pg_settings
17WHERE
18 -- Error Handling
19 category ILIKE '%Error%';

Purpose and Functionality

This PostgreSQL query retrieves configuration parameters specifically related to error handling from the pg_settings system catalog. It helps database administrators understand current error management settings, their values, and operational status.

PostgreSQL Developer Settings Query via pg_settings

Fri, 05 Sep 2025 00:00:00 +0000

PostgreSQL Developer Settings Query: How to View Database Configuration Options

This PostgreSQL query allows database administrators and developers to examine developer-specific configuration settings in their PostgreSQL database. The query targets the pg_settings system catalog to retrieve detailed information about parameters that affect development and debugging processes.

Query Purpose

The SQL code retrieves developer-related configuration parameters from PostgreSQL's system catalog. This information helps developers understand current database settings that impact development workflows, debugging capabilities, and performance tuning options specifically designed for development environments.

PostgreSQL Connection Settings Query via pg_settings

Thu, 04 Sep 2025 00:00:00 +0000

PostgreSQL Connection Settings Query - Complete Guide to pg_settings

This PostgreSQL query provides database administrators with essential connection configuration parameters by querying the pg_settings system view. Understanding these settings is crucial for optimizing database connectivity and troubleshooting connection-related issues.

Query Breakdown

The provided query retrieves connection-specific configuration parameters from PostgreSQL's system catalog:

 1SELECT
 2 name,
 3 setting,
 4 -- category,
 5 vartype,
 6 short_desc,
 7 -- enumvals,
 8 source,
 9 min_val,
10 max_val,
11 boot_val,
12 reset_val,
13 -- not available on PostgreSQL < 9.5
14 pending_restart
15FROM
16 pg_settings
17WHERE
18 -- Connections and Authentication / Connection Settings
19 category ILIKE '% / Connection Settings%';

Purpose and Functionality

This query serves multiple administrative purposes by extracting connection-related configuration parameters that control how PostgreSQL handles client connections. The pg_settings view provides a comprehensive interface to PostgreSQL's configuration parameters, making it invaluable for database tuning and troubleshooting.

PostgreSQL Compatibility Settings Query via pg_settings

Wed, 03 Sep 2025 00:00:00 +0000

PostgreSQL Compatibility Settings Query: Complete Guide to pg_settings Analysis

This PostgreSQL query extracts compatibility-related configuration parameters from the pg_settings system catalog, providing essential insights into version and platform compatibility settings for database administrators.

Purpose and Overview

The query targets PostgreSQL's pg_settings system view to identify all configuration parameters related to compatibility settings. This is particularly valuable for database administrators managing PostgreSQL installations across different versions, platforms, or when migrating from other database systems.

PostgreSQL Client Connection Settings via pg_settings

Tue, 02 Sep 2025 00:00:00 +0000

PostgreSQL Client Connection Settings: Complete Guide to pg_settings Query

This PostgreSQL query provides a comprehensive view of client connection default settings by querying the pg_settings system view, allowing database administrators to analyze and understand configuration parameters that affect client behavior.

Purpose and Overview

The query retrieves essential configuration parameters related to client connection defaults from PostgreSQL's pg_settings view. This system view contains all configuration parameters currently loaded by the PostgreSQL server, making it invaluable for database administration and troubleshooting connection-related issues.

PostgreSQL Autovacuum Settings Query via pg_settings

Mon, 01 Sep 2025 00:00:00 +0000

PostgreSQL Autovacuum Settings Query: Complete Guide to pg_settings Analysis

This PostgreSQL query provides database administrators with essential insights into autovacuum configuration parameters by querying the pg_settings system view. Understanding these settings is crucial for optimal database performance and maintenance.

Purpose

The primary purpose of this query is to extract and analyze all autovacuum-related configuration parameters from a PostgreSQL database. This information helps database administrators monitor, troubleshoot, and optimize automatic vacuum operations that are essential for maintaining database performance and preventing transaction ID wraparound issues.

PostgreSQL Authentication Settings Query for Admins

Wed, 27 Aug 2025 00:00:00 +0000

PostgreSQL Authentication Settings Query for Admins

Managing PostgreSQL at scale requires both fine-grained control and visibility into configuration parameters. One valuable system catalog, pg_settings, provides administrators direct insight into runtime parameters, defaults, and constraints that govern PostgreSQL’s behavior.

In this guide, we’ll explore a practical SQL query for extracting authentication-related configuration settings in PostgreSQL. This is especially useful for database administrators (DBAs) focused on optimizing security, troubleshooting, and compliance.

pg_settings — Query PostgreSQL Configuration Parameters

Tue, 26 Aug 2025 00:00:00 +0000

pg_settings — Query PostgreSQL Configuration Parameters

The live configuration PostgreSQL is running with and the values written in postgresql.conf are not always the same. A parameter that requires a server restart has already been updated in the file but the old value is still in effect. A reload that produced a parse error left one directive silently inactive. A setting changed at the session level masks whatever the config file says. None of these discrepancies are visible in the config file alone, and none raise an obvious error in the application log. pg_settings shows the runtime state of every GUC parameter — what value the server is using right now, what file set it, and whether a restart is pending to apply a queued change. pg_file_settings shows what the configuration files say and, critically, whether each directive was successfully applied or blocked by an error. Querying both together is the complete picture any configuration investigation needs.

Monitor PostgreSQL Active Sessions with pg_stat_activity

Mon, 25 Aug 2025 00:00:00 +0000

Monitoring PostgreSQL Active Sessions with pg_stat_activity Explained

As databases scale, monitoring active connections and queries in PostgreSQL becomes essential for performance tuning, troubleshooting, and ensuring stability. PostgreSQL provides a powerful system view called pg_stat_activity that contains detailed information about all current backend processes.

The following query allows database administrators to inspect active sessions:

 1SELECT
 2 pid,
 3 usename,
 4 client_addr,
 5 client_hostname,
 6 client_port,
 7 backend_start,
 8 query_start,
 9 state,
10 -- not available on PostgreSQL < 10
11 backend_type
12FROM
13 pg_stat_activity
14ORDER BY
15 -- not available on PostgreSQL < 10
16 backend_type;

Purpose of the Query

This query helps you:

Monitor Running Queries in PostgreSQL using pg_stat_activity

Mon, 18 Aug 2025 00:00:00 +0000

Monitor Running Queries in PostgreSQL (9.2+ and Newer)

Overview

When managing a PostgreSQL database, one of the most important tasks for database administrators and developers is monitoring currently running queries. This helps identify problematic sessions, troubleshoot performance bottlenecks, and optimize long-running queries. The query uses PostgreSQL’s built-in view pg_stat_activity to list all active queries.

Purpose of the Query

This query helps database administrators:

Identify active queries running in PostgreSQL.
Detect long-running queries that may indicate performance issues.
Troubleshoot query locks, blocking sessions, or resource-heavy operations.
Exclude the monitoring query itself (by filtering out references to pg_stat_activity).

Sample Code from Command Line

 1SELECT
 2 pid,
 3 age(clock_timestamp(), query_start),
 4 usename,
 5 application_name,
 6 query
 7FROM
 8 pg_stat_activity
 9WHERE
10 state != 'idle'
11 AND
12 query NOT ILIKE '%pg_stat_activity%'
13ORDER BY
14 query_start DESC;

Breakdown & Key Points

pid → The process ID of the backend running the query. Useful for terminating queries with pg_terminate_backend(pid).
age(clock_timestamp(), query_start) → Shows how long the query has been running. This helps spot queries consuming excessive execution time.
usename → Username of the session owner running the query.
application_name → Identifies the client application connected to PostgreSQL (e.g., psql, PgAdmin, or a custom app).
query → The actual SQL text being executed by the session.
state != 'idle' → Ensures only active queries are displayed (ignores idle connections).
query NOT ILIKE '%pg_stat_activity%' → Prevents including this very monitoring query in the results.
ORDER BY query_start DESC → Orders results by start time, showing the most recent queries first.

Key Insights & Use Cases

Performance Monitoring
Quickly detect slow queries running for a long time, which may block other transactions.
Troubleshooting Client Applications
Identify which users or applications are causing heavy loads.
Database Administration
Track down sessions that need to be terminated when they consume too many resources or lock critical tables.
Query Optimization
By regularly monitoring queries, you can collect evidence on what queries should be indexed, rewritten, or cached.

Best Practices

Use this query as a foundation for building monitoring dashboards.
Automate alerts for long-running queries (e.g., > 5 minutes).
Combine with PostgreSQL’s pg_locks view when troubleshooting deadlocks or lock waits.
Consider lightweight monitoring tools like pg_stat_statements for aggregate query statistics.

References & Further Reading

PostgreSQL Official Docs: pg_stat_activity
PostgreSQL Wiki: Monitoring Queries
Tooling: pgAdmin, pgbadger, and custom dashboards for query monitoring.

ALTER SEQUENCE RESTART WITH in PostgreSQL — Examples

Sun, 17 Aug 2025 00:00:00 +0000

Restarting All PostgreSQL Sequences with SQL Script

Database administrators often face challenges with PostgreSQL sequences, especially after data has been deleted or when tables have been re-imported. Sequences drive the generation of auto-incrementing values (like primary keys using SERIAL or BIGSERIAL), and sometimes they need to be reset or restarted.

This guide covers a simple SQL script that restarts all PostgreSQL sequences across your database, making it easier to bring sequences back in sync with your table data.

How to Monitor Slow Running Queries in PostgreSQL

Mon, 19 May 2025 00:00:00 +0000

PostgreSQL Query for Monitoring Slow Running Queries

Purpose

Monitoring and optimizing database performance is critical for any production environment. One common challenge is identifying slow queries that may impact overall system responsiveness. This article explains how to use a PostgreSQL SQL query to find currently executing queries that have been running for more than 30 seconds, providing a practical alternative to the traditional slow query log.

Analyze PostgreSQL Cache-Hit Ratio with pg_stat_statements

Sun, 18 May 2025 00:00:00 +0000

How to Analyze PostgreSQL Query Cache-Hit Ratio Using pg_stat_statements

Purpose

Measuring the cache-hit ratio of your PostgreSQL queries is essential for understanding and optimizing how efficiently your database serves data from memory versus disk. This article explains how to use the pg_stat_statements extension to analyze cache-hit ratios, why this metric matters, and how to interpret and act on the results for improved database performance.

PostgreSQL Lock Monitoring Uncover Query Details and Lock Age

Mon, 02 Sep 2024 00:00:00 +0000

PostgreSQL Lock Monitoring: Gain Insights into Locks with Query and Age

Purpose

This PostgreSQL SQL query equips you to monitor locks held by active database sessions along with their associated queries and age. This detailed information proves invaluable for performance tuning, troubleshooting lock conflicts, and understanding database behavior.

Sample Code from Command Line

 1SELECT
 2 a.datname,
 3 l.relation::regclass,
 4 l.transactionid,
 5 l.mode,
 6 l.GRANTED,
 7 a.usename,
 8 a.query,
 9 a.query_start,
10 age(now(), a.query_start) AS "age",
11 a.pid
12FROM
13 pg_stat_activity a
14JOIN
15 pg_locks l
16ON
17 l.pid = a.pid
18ORDER BY
19 a.query_start;

Code Breakdown:

Identify & Resolve Blocking Application Locks in PostgreSQL

Sun, 01 Sep 2024 00:00:00 +0000

PostgreSQL Lock Monitoring: Identify Blocking Locks and Resolve Application Conflicts

Purpose

In a busy PostgreSQL environment, transactions can sometimes become blocked, waiting for other transactions to release locks. This can slow performance and even cause stalls. This article dissects a powerful PostgreSQL script designed to expose blocked processes, offering insights to help you troubleshoot and optimize performance.

Sample Code from Command Line

 1SELECT
 2 blocked_locks.pid AS blocked_pid,
 3 blocked_activity.usename AS blocked_user,
 4 blocking_locks.pid AS blocking_pid,
 5 blocking_activity.usename AS blocking_user,
 6 blocked_activity.query AS blocked_statement,
 7 blocking_activity.query AS current_statement_in_blocking_process,
 8 blocked_activity.application_name AS blocked_application,
 9 blocking_activity.application_name AS blocking_application
10FROM
11 pg_catalog.pg_locks blocked_locks
12JOIN
13 pg_catalog.pg_stat_activity blocked_activity
14ON
15 blocked_activity.pid = blocked_locks.pid
16JOIN
17 pg_catalog.pg_locks blocking_locks
18ON
19 blocking_locks.locktype = blocked_locks.locktype
20 AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
21 AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
22 AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
23 AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
24 AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
25 AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
26 AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
27 AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
28 AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
29 AND blocking_locks.pid != blocked_locks.pid
30JOIN
31 pg_catalog.pg_stat_activity blocking_activity
32ON
33 blocking_activity.pid = blocking_locks.pid
34WHERE
35 NOT blocked_locks.granted;

Code Breakdown: The query accomplishes this by joining several system views:

PostgreSQL Performance Monitoring: Identify Slow Queries

Sat, 31 Aug 2024 00:00:00 +0000

PostgreSQL: Identify Slow Running Queries in Real-Time

Purpose

This PostgreSQL SQL query provides a real-time snapshot of queries currently executing on your database that have been running for more than 30 seconds. It acts as a powerful alternative to a traditional slow query log, helping you proactively identify and troubleshoot performance bottlenecks without relying solely on historical logs.

Sample Code from Command Line

 1SELECT
 2 now() - query_start as "runtime",
 3 usename,
 4 datname,
 5 wait_event,
 6 state,
 7 query
 8FROM
 9 pg_stat_activity
10WHERE
11 now() - query_start > '30 seconds'::interval
12ORDER BY
13 runtime DESC;

Code Breakdown:

Boost PostgreSQL Efficiency with Cache Hit Ratio Analysis

Fri, 30 Aug 2024 00:00:00 +0000

PostgreSQL Performance Tuning: Analyze Cache Hit Ratio with pg_stat_statements

Purpose

This PostgreSQL query empowers you to gain critical insights into the efficiency of your query workload by measuring the cache hit ratio from the pg_stat_statements extension. Cache hit ratio is a crucial metric for evaluating how effectively your database utilizes its memory buffers to serve query results. By identifying queries with low hit ratios, you can pinpoint potential areas for optimization, such as improving indexing strategies or adjusting memory allocation.

Analyze PostgreSQL Query Times with pg_stat_statements

Thu, 29 Aug 2024 00:00:00 +0000

PostgreSQL Performance Diagnostics: Analyze Query Times with pg_stat_statements

Purpose

This PostgreSQL SQL query utilizes the power of the pg_stat_statements extension to provide you with essential insights into query performance. It retrieves crucial metrics like total execution time, average execution time, minimum and maximum execution times, and even the standard deviation of execution times. Armed with this information, you can identify slow-running queries, pinpoint performance bottlenecks, and make data-driven decisions for optimization.

pg_is_in_recovery — Monitor PostgreSQL Standby Status

Wed, 28 Aug 2024 00:00:00 +0000

PostgreSQL Recovery Monitoring: Gain Real-Time Insights with SQL

Purpose

This PostgreSQL SQL query provides critical information about the current recovery status of your database. By utilizing a combination of system functions and conditional logic, it delivers a snapshot of whether the database is in backup or recovery mode, the backup start time, and additional details about the recovery process itself. This information is invaluable for database administrators and DevOps engineers to monitor, troubleshoot, and optimize database recovery operations.

Prioritize PostgreSQL Table Analysis for Performance

Thu, 25 Apr 2024 00:00:00 +0000

Prioritize PostgreSQL Table Analysis: Unlocking Performance Insights

Maintaining optimal PostgreSQL database performance requires regular table analysis. This process lets the query planner make informed decisions based on accurate table statistics. This article dives into a valuable PostgreSQL script revealing tables needing analysis, explains its components, and highlights how to optimize your database.

Sample Code from Command Line

 1SELECT
 2 schemaname,
 3 relname,
 4 -- not available on PostgreSQL <= 9.3
 5 n_mod_since_analyze,
 6 last_analyze,
 7 last_autoanalyze,
 8 -- not available on PostgreSQL <= 9.0
 9 analyze_count,
10 autoanalyze_count
11FROM pg_stat_user_tables
12ORDER BY
13 n_mod_since_analyze DESC,
14 last_analyze DESC,
15 last_autoanalyze DESC;

Postgres Pre 9.4 SQL

PostgreSQL Performance: VACUUM, ANALYZE, and Bloat

Wed, 24 Apr 2024 00:00:00 +0000

PostgreSQL Performance Boost: Understanding Vacuum, Analyze, and Bloat

Maintaining peak PostgreSQL database performance means understanding the crucial processes of vacuuming and analysis. Left unchecked, dead tuples (deleted or updated rows) can lead to table bloat, slowing queries and wasting space. This article explains a PostgreSQL script that reveals bloat, shows how VACUUM and ANALYZE optimize your database, and offers essential insights.

Sample Code from Command Line

 1SELECT
 2 schemaname,
 3 relname,
 4 n_live_tup,
 5 n_dead_tup,
 6 n_dead_tup / GREATEST(n_live_tup + n_dead_tup, 1)::float * 100 AS dead_percentage,
 7 n_mod_since_analyze,
 8 last_vacuum,
 9 last_autovacuum,
10 last_analyze,
11 last_autoanalyze,
12 vacuum_count,
13 autovacuum_count,
14 analyze_count,
15 autoanalyze_count
16FROM
17 pg_stat_user_tables
18ORDER BY
19 n_dead_tup DESC,
20 n_mod_since_analyze DESC,
21 last_vacuum DESC,
22 last_analyze DESC,
23 last_autovacuum DESC,
24 last_autoanalyze DESC;

Postgres Pre 9.4 SQL

Mastering PostgreSQL Locks: Troubleshooting & Insights

Tue, 23 Apr 2024 00:00:00 +0000

Mastering PostgreSQL Locks: Troubleshooting and Performance Insights

In a busy PostgreSQL database, multiple transactions might try to access the same resources simultaneously. Locks are PostgreSQL's way of handling concurrency, ensuring data consistency and preventing conflicts. This article dives into PostgreSQL lock monitoring, explaining the provided scripts, troubleshooting techniques, and how to optimize performance when lock contention occurs.

Sample Code from Command Line

 1SELECT
 2 t.schemaname,
 3 t.relname,
 4 -- l.database, -- id number is less useful, take schemaname from join instead
 5 l.locktype,
 6 page,
 7 virtualtransaction,
 8 pid,
 9 mode,
10 granted
11FROM
12 pg_locks l,
13 --pg_stat_user_tables t
14 pg_stat_all_tables t
15WHERE
16 l.relation = t.relid
17ORDER BY
18 relation ASC;
19
20SELECT
21 relation::regclass AS relation_regclass,
22 *
23FROM
24 pg_locks
25WHERE
26 NOT granted;

Notes List PostgreSQL Locks. Tested on PostgreSQL 8.4, 9.x, 10.x, 11.x, 12.x, 13.0

PostgreSQL Lock Troubleshooting, Unlocking Blocked Processes

Mon, 22 Apr 2024 00:00:00 +0000

PostgreSQL Lock Troubleshooting: Unlocking Blocked Processes

Sample Code from Command Line

 1SELECT
 2 blocked_locks.pid AS blocked_pid,
 3 blocked_activity.usename AS blocked_user,
 4 blocking_locks.pid AS blocking_pid,
 5 blocking_activity.usename AS blocking_user,
 6 blocked_activity.query AS blocked_statement,
 7 blocking_activity.query AS current_statement_in_blocking_process
 8FROM
 9 pg_catalog.pg_locks AS blocked_locks
10JOIN
11 pg_catalog.pg_stat_activity AS blocked_activity
12ON
13 blocked_activity.pid = blocked_locks.pid
14JOIN
15 pg_catalog.pg_locks AS blocking_locks
16ON
17 blocking_locks.locktype = blocked_locks.locktype
18 AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
19 AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
20 AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
21 AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
22 AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
23 AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
24 AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
25 AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
26 AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
27 AND blocking_locks.pid != blocked_locks.pid
28JOIN
29 pg_catalog.pg_stat_activity blocking_activity
30ON
31 blocking_activity.pid = blocking_locks.pid
32WHERE
33 NOT blocked_locks.granted;

Notes List PostgreSQL locks blocked. Requires PostgreSQL 9.2+. Tested on PostgreSQL 9.2+, 10.x, 11.x, 12.x, 13.0.

Identifying Unused PostgreSQL Indexes to Declutter & Optimize

Wed, 10 Apr 2024 00:00:00 +0000

Understanding Your PostgreSQL Index Cache Hit Ratio: Optimizing Performance

In PostgreSQL, keeping frequently accessed data readily available is crucial for optimal query performance. Indexes act as shortcuts, enabling the database to locate specific data within tables faster. The PostgreSQL cache plays a vital role in this process, storing frequently used index pages for quicker retrieval. The cache hit ratio is a key metric that tells you how effectively your cache is serving up these indexed pages.

Understanding Your PostgreSQL Index Cache Hit Ratio

Tue, 09 Apr 2024 00:00:00 +0000

Identifying Unused Indexes in PostgreSQL: Optimizing Storage and Performance

In PostgreSQL, indexes act as shortcuts, accelerating data retrieval within tables. However, unused indexes can become a burden, consuming storage space and potentially impacting performance. This article explores a PostgreSQL code snippet designed to identify unused indexes and explains its significance for database administrators and developers.

Sample Code from Command Line

 1SELECT
 2 relname AS table,
 3 indexrelname AS index,
 4 idx_scan,
 5 idx_tup_read,
 6 idx_tup_fetch,
 7 pg_size_pretty(pg_relation_size(indexrelname::regclass))
 8FROM
 9 pg_stat_all_indexes
10WHERE
11 schemaname = 'public'
12 AND
13 idx_scan = 0
14 AND
15 idx_tup_read = 0
16 AND
17 idx_tup_fetch = 0
18ORDER BY
19 pg_relation_size(indexrelname::regclass) DESC;

Notes PostgreSQL unused indexes. Tested on PostgreSQL 8.4, 9.x, 10.x, 11.x, 12.x, 13.0.

Query the PostgreSQL Configuration

Mon, 08 Apr 2024 00:00:00 +0000

Your PostgreSQL Configuration

This blog post empowers you to gain valuable insights into your PostgreSQL database configuration. We'll delve into the provided SQL code, explain its purpose, and equip you with key points and insights to effectively manage your PostgreSQL instance.

Sample Code from Command Line

PostgreSQL >= 11.9

 1SELECT
 2 current_setting('config_file') AS "config_file",
 3 current_setting('hba_file') AS "hba_file",
 4 current_setting('ident_file') AS "ident_file";
 5
 6SELECT
 7 current_setting('data_directory') AS "data_directory",
 8 current_setting('external_pid_file') AS "external_pid_file";
 9
10SELECT
11 current_setting('unix_socket_directories') AS "unix_socket_directories",
12 current_setting('unix_socket_permissions') AS "unix_socket_permissions",
13 current_setting('unix_socket_group') AS "unix_socket_group";
14
15SELECT
16 -- not available on PostgreSQL < 10
17 pg_current_logfile(),
18 current_setting('log_directory') AS "log_directory", -- log
19 current_setting('log_filename') AS "log_filename"; -- postgresql-%Y-%m-%d_%H%M%S.log
20
21SELECT
22 -- CASE WHEN pg_current_logfile() IS NOT NULL THEN pg_ls_logdir() END AS pg_ls_logdir,
23 pg_ls_waldir(),
24 -- not available on PostgreSQL <= 11.8
25 pg_ls_archive_statusdir(),
26 pg_ls_tmpdir();

Pre PosgreSQL 10

Keep Your PostgreSQL Database Clean, Identify Idle Connections

Sun, 07 Apr 2024 00:00:00 +0000

Identify Idle PostgreSQL Connections: Keep Your Database Clean

This blog post equips you with the knowledge to identify and potentially terminate stale connections within your PostgreSQL database. We'll delve into the provided SQL code, explain its purpose, and offer valuable insights for maintaining optimal database performance.

Sample Code from Command Line

 1SELECT
 2 rank() over (partition by client_addr order by backend_start ASC) as rank,
 3 pid,
 4 backend_start,
 5 query_start,
 6 state_change,
 7 datname,
 8 usename,
 9 client_addr
10FROM
11 pg_stat_activity
12WHERE
13 -- don't kill yourself
14 pid <> pg_backend_pid()
15 -- AND
16 -- don't kill your admin tools
17 --application_name !~ '(?:psql)|(?:pgAdmin.+)'
18 -- AND
19 --usename not in ('postgres')
20 AND
21 query in ('')
22 AND
23 (
24 (current_timestamp - query_start) > interval '10 minutes'
25 OR
26 (query_start IS NULL AND (current_timestamp - backend_start) > interval '10 minutes')
27 )
28;

Notes List PostgreSQL stale connections that have been idle > 10 mins. Can be used to kill connections using the pids returned, eg. ( SELECT pg_terminate_backend(pid))

Optimize Your PostgreSQL Queries, Index Cardinality

Sat, 06 Apr 2024 00:00:00 +0000

PostgreSQL Index Cardinality: A Guide to Understanding Index Efficiency

This blog post delves into the world of PostgreSQL index cardinality, a crucial metric for optimizing database performance. We'll dissect the provided SQL code, explain its purpose, and equip you with valuable insights to make informed decisions about your PostgreSQL indexes.

Sample Code from Command Line

 1SELECT
 2 relname,
 3 --relkind,
 4 reltuples AS "cardinality (reltuples)",
 5 relpages
 6FROM
 7 pg_class
 8WHERE
 9 relkind = 'i'
10-- AND
11-- relname LIKE 'someprefix%';
12 AND
13 relname NOT ILIKE 'pg_%'
14ORDER BY
15 2 DESC;

Notes PostgreSQL index cardinality. Tested on PostgreSQL 8.4, 9.x, 10.x, 11.x, 12.x, 13.0.

Unveiling Your PostgreSQL Server - A Diagnostic Powerhouse

Thu, 04 Apr 2024 00:00:00 +0000

Unveiling Your PostgreSQL Server: A Treasure Trove of Information

This comprehensive PostgreSQL script delves into the inner workings of your database server, revealing valuable details about its version, configuration, connections, users, and more. It empowers database administrators and developers with insights to optimize performance, manage resources, and ensure smooth operation.

Sample Code from Command Line

 1\timing off
 2
 3-- ========================================================================== --
 4-- V e r s i o n
 5-- ========================================================================== --
 6
 7--\pset title 'PostgreSQL Version'
 8
 9-- version() returns a long human readable string, hence we split from others SELECTs eg.
 10-- PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
 11SELECT
 12 version(),
 13 current_setting('server_version') AS "server_version",
 14 current_setting('server_version_num') AS "server_version_num";
 15
 16-- ========================================================================== --
 17-- S e r v e r D e t a i l s
 18-- ========================================================================== --
 19
 20\echo
 21--\pset title 'PostgreSQL Server Details'
 22
 23SELECT
 24 pg_postmaster_start_time(),
 25 pg_conf_load_time(),
 26 current_setting('logging_collector') AS "logging_collector",
 27 current_setting('log_destination') AS "log_destination",
 28 -- not available in Postgres 9
 29 -- doesn't work because it still checks if pg_current_logfile() is valid and neither eval or execute seem to work around this
 30 -- CASE WHEN current_setting('server_version_num')::int > 100000 THEN pg_current_logfile() ELSE NULL END as pg_current_logfile
 31 pg_current_logfile()
 32 -- current_setting('log_directory') AS "log_directory", -- log
 33 -- current_setting('log_filename') AS "log_filename", -- postgresql-%Y-%m-%d_%H%M%S.log
 34 -- not available on Postgres 10
 35 --pg_jit_available()
 36;
 37
 38-- SELECT pg_reload_conf(), pg_rotate_logfile();
 39
 40-- pg_sleep(1.5)
 41-- pg_sleep_for('5 minutes')
 42-- pg_sleep_until('tomorrow 03:00')
 43
 44-- ======================================================
 45-- https://www.postgresql.org/docs/12/runtime-config.html
 46
 47-- set runtime config at system, database, or user level, or even user level for a specific database (eg. for an ETL user to set different memory settings for use in a given DB)
 48-- ALTER SYSTEM SET timezone = 'UTC';
 49-- ALTER DATABASE test SET timezone = 'UTC';
 50-- ALTER USER hari SET timezone = 'UTC';
 51-- ALTER USER hari IN DATABASE test SET timezone = 'UTC';
 52
 53-- session level:
 54-- SET myParam TO 'myValue';
 55-- UPDATE pg_settings SET setting = 'myValue' WHERE name = 'myParam';
 56
 57-- \x
 58-- SELECT * from pg_settings;
 59
 60-- SHOW ALL;
 61-- SHOW one_param;
 62
 63\echo
 64--\pset title 'Config Files'
 65
 66SELECT
 67 current_setting('config_file') AS "config_file",
 68 current_setting('hba_file') AS "hba_file",
 69 current_setting('ident_file') AS "ident_file";
 70
 71\echo
 72--\pset title 'PostgreSQL Data Directory & Unix Sockets'
 73
 74SELECT
 75 current_setting('data_directory') AS "data_directory",
 76 current_setting('unix_socket_directories') AS "unix_socket_directories",
 77 current_setting('unix_socket_permissions') AS "unix_socket_permissions",
 78 current_setting('unix_socket_group') AS "unix_socket_group";
 79
 80-- ========================================================================== --
 81-- B u f f e r s & C o n n e c t i o n s
 82-- ========================================================================== --
 83
 84\echo
 85--\pset title 'Buffers & Connections'
 86
 87SELECT
 88 current_setting('shared_buffers') AS "shared_buffers",
 89 current_setting('work_mem') AS "work_mem",
 90 current_setting('max_connections') AS "max_connections",
 91 current_setting('max_files_per_process') AS "max_files_per_process", -- should be less than ulimit nofiles to avoid “Too many open files” failures
 92 current_setting('track_activities') AS "track_activities", -- for pg_stat / pg_statio family of system views that are used in many other adjacent scripts
 93 current_setting('track_counts') AS "track_counts", -- needed for the autovacuum daemon
 94 current_setting('password_encryption') AS "password_encryption";
 95
 96
 97-- ========================================================================== --
 98-- U s e r
 99-- ========================================================================== --
100
101\echo
102--\pset title 'Users, Sessions & Queries'
103
104-- in SQL the following have special syntax and should be called without parens: current_catalog, current_role, current_schema, current_user, session_user
105SELECT
106 current_user, -- aka user, current_role - this is the effective user for permission checking
107 session_user, -- connection user before superuser SET SESSION AUTHORIZATION
108 current_schema,
109 current_catalog, -- SQL standard, same as current_database()
110 pg_backend_pid(),
111 current_query();
112
113\echo
114--\pset title 'Schema search list'
115
116SELECT current_schemas(true) AS "current_schemas(true) - auto-searched schemas"; -- true to include implicit schemas eg. pg_catalog
117
118
119-- ========================================================================== --
120-- B a c k u p & R e c o v e r y
121-- ========================================================================== --
122
123\echo
124--\pset title 'Backup & Recovery'
125
126SELECT
127 pg_is_in_backup(),
128 pg_is_in_recovery(),
129 pg_backup_start_time(),
130 'see postgres_recovery.sql for more info' AS "info";
131 -- use postgres_recovery.sql instead of having a big blank table distracting us here
132 -- the following recovery control functions can only be executed during recovery - to get just the above use postgres_funcs.sql
133 --( CASE WHEN pg_is_in_recovery() THEN pg_is_wal_replay_paused() END) AS "pg_is_wal_replay_paused()",
134 --( CASE WHEN pg_is_in_recovery() THEN pg_last_wal_receive_lsn() END) AS "pg_last_wal_receive_lsn()",
135 --( CASE WHEN pg_is_in_recovery() THEN pg_last_wal_replay_lsn() END) AS "pg_last_wal_replay_lsn()",
136 --( CASE WHEN pg_is_in_recovery() THEN pg_last_xact_replay_timestamp() END) AS "pg_last_xact_replay_timestamp()"
137
138--SELECT
139-- pg_ls_logdir(),
140-- pg_ls_waldir(),
141-- pg_ls_archive_statusdir(),
142-- pg_ls_tmpdir();
143
144
145-- ========================================================================== --
146-- N e t w o r k
147-- ========================================================================== --
148
149\echo
150--\pset title 'Networking'
151
152SELECT
153 inet_client_addr(),
154 inet_client_addr(),
155 inet_server_addr(),
156 inet_server_port();
157
158-- causes 0 rows when mixed with other select funcs
159--SELECT pg_listening_channels();
160
161
162-- ========================================================================== --
163-- D a t e & T i m e
164-- ========================================================================== --
165
166-- CURRENT_TIME and CURRENT_TIMESTAMP deliver values with time zone; LOCALTIME and LOCALTIMESTAMP deliver values without time zone.
167-- CURRENT_TIME, CURRENT_TIMESTAMP, LOCALTIME, and LOCALTIMESTAMP can optionally take a precision parameter, which causes the result to be rounded to that many fractional digits in the seconds field
168
169\echo
170--\pset title 'Date & Time'
171
172SELECT
173 -- current timestamps even inside transactions/functions
174 now(),
175 timeofday(), -- human string timestamp with timezone
176
177 -- at start of current transaction for consistency, includes +offset timezone
178 current_timestamp(2) AS "current_timestamp(2)", -- secs precision of 2 decimal places, includes +offset timezone
179 current_date,
180 current_time(1) AS "current_time(1)", -- includes +offset timezone
181 localtime,
182 localtimestamp(1) AS "localtimestamp(1)",
183
184 -- provide current timestamps even inside transactions/functions
185 -- now()
186 -- timeofday(), -- human string timestamp with timezone
187 clock_timestamp(), -- current date + time (changes throughout function)
188 statement_timestamp(),
189 transaction_timestamp() -- same as CURRENT_TIMESTAMP
190;
191
192--\pset title

Notes Useful PostgreSQL functions & info. Requires PostgreSQL 10+ (see postgres_info_pre10.sql for PostgreSQL 8/9). Tested on PostgreSQL 10.x, 11.x, 12.x, 13.0.

Identify Underutilized PostgreSQL Columns for Optimization

Wed, 03 Apr 2024 00:00:00 +0000

Identifying Underutilized Columns in Your PostgreSQL Database

Keeping your PostgreSQL database clean and efficient is crucial for optimal performance. One way to achieve this is by identifying and potentially removing "useless" columns – those that hold minimal or redundant data. This article explores a PostgreSQL code snippet designed to unearth such columns, helping you optimize your database schema.

Sample Code from Command Line

 1SELECT
 2 nspname,
 3 relname,
 4 attname,
 5 typname,
 6 (stanullfrac*100)::int AS null_percent,
 7 case
 8 when stadistinct >= 0
 9 then stadistinct
10 else
11 abs(stadistinct)*reltuples
12 end AS "distinct",
13 case 1
14 when stakind1
15 then stavalues1
16 when stakind2
17 then stavalues2
18 end AS "values"
19FROM
20 pg_class c
21JOIN
22 pg_namespace ns
23ON
24 (ns.oid=relnamespace)
25JOIN
26 pg_attribute
27ON
28 (c.oid=attrelid)
29JOIN
30 pg_type t
31ON
32 (t.oid=atttypid)
33JOIN
34 pg_statistic
35ON
36 (c.oid=starelid AND staattnum=attnum)
37WHERE
38 nspname NOT LIKE E'pg\\_%'
39 AND
40 nspname != 'information_schema'
41 AND
42 relkind = 'r'
43 AND
44 NOT attisdropped
45 AND
46 attstattarget != 0
47 AND
48 reltuples >= 100
49 AND
50 stadistinct BETWEEN 0 AND 1
51ORDER BY
52 nspname,
53 relname,
54 attname;

Notes: Finds useless PostgreSQL columns containing only a single value eg. all NULLs or a redundant non-distinguishing field. Only returns columns with over 100 rows. Tested on PostgreSQL 8.4, 9.x, 10.x, 11.x, 12.x, 13.0

Assess PostgreSQL Database Sizes Quickly and Easily

Tue, 02 Apr 2024 00:00:00 +0000

Quickly Assess Your PostgreSQL Database Landscape by Size

Managing multiple PostgreSQL databases requires an understanding of their storage footprint. This article introduces a simple yet effective PostgreSQL code snippet that helps you quickly determine the size of each database in your system, ordered by their storage consumption (descending).

Sample Code from Command Line

1SELECT
2 datname,
3 pg_size_pretty(pg_database_size(datname))
4FROM
5 pg_database
6ORDER
7 BY pg_database_size(datname) DESC;

Notes: PostgreSQL databases by size descending. Tested on PostgreSQL 8.4, 9.x, 10.x, 11.x, 12.x, 13.0.

List PostgreSQL Databases by Size with Access Check

Mon, 01 Apr 2024 00:00:00 +0000

List Your PostgreSQL Databases by Size (With Access Check)

Keeping your PostgreSQL database server organized is crucial for optimal performance and manageability. A critical aspect of this organization is understanding the storage footprint of each database. This SQL code snippet empowers you to efficiently retrieve a list of all your PostgreSQL databases, sorted by their size in descending order, while also indicating whether you have access to connect to each database.

pg_blocking_pids — Find Blocking Queries in PostgreSQL

Mon, 25 Mar 2024 00:00:00 +0000

Identifying Blocking PostgreSQL Queries: A Guide for Database Administrators

This article explores a PostgreSQL query designed to identify currently blocked database queries and the processes (identified by PIDs) responsible for blocking them. This information is crucial for database administrators troubleshooting performance bottlenecks and ensuring smooth database operation.

Sample Code from Command Line

1SELECT
2 pid,
3 usename,
4 pg_blocking_pids(pid) AS blocked_by_pids,
5 query AS blocked_query
6FROM
7 pg_stat_activity
8WHERE
9 cardinality(pg_blocking_pids(pid)) > 0;

Notes: Lists PostgreSQL queries blocked along with the pids of those holding the locks blocking them. Requires PostgreSQL >= 9.6. Tested on PostgreSQL 9.6+, 10.x 11.x, 12.x, 13.0.

PostgreSQL query to find columns containing only NULL values

Sun, 24 Mar 2024 00:00:00 +0000

Identifying Null-Only Columns in PostgreSQL

This article explores a valuable PostgreSQL query for database administrators. It helps identify columns within your database tables that exclusively contain NULL values. Uncovering these "null-only" columns can be a key step in optimizing storage usage and streamlining your database schema design.

Sample Code from Command Line

 1SELECT
 2 nspname,
 3 relname,
 4 attname,
 5 typname,
 6 (
 7 stanullfrac*100
 8 )
 9 ::int AS null_percent
10FROM
11 pg_class c
12 JOIN
13 pg_namespace ns
14 ON (ns.oid = relnamespace)
15 JOIN
16 pg_attribute
17 ON (c.oid = attrelid)
18 JOIN
19 pg_type t
20 ON (t.oid = atttypid)
21 JOIN
22 pg_statistic
23 ON (c.oid = starelid
24 AND staattnum = attnum)
25WHERE
26 (
27 stanullfrac*100
28 )
29 ::int = 100
30 AND nspname NOT LIKE E'pg\\_%'
31 AND nspname != 'information_schema'
32 AND relkind = 'r'
33 AND NOT attisdropped
34 AND attstattarget != 0 -- AND
35 --reltuples >= 100
36ORDER BY
37 nspname,
38 relname,
39 attname;

Notes: Finds PostgreSQL columns that contain only NULLs. Tested on PostgreSQL 8.4, 9.x, 10.x, 11.x, 12.x, 13.0.

Monitoring Active PostgreSQL Queries for Performance

Fri, 22 Mar 2024 00:00:00 +0000

Monitoring Active Queries in PostgreSQL for Performance Optimization

Introduction

Ensuring smooth database performance is crucial for modern applications. In PostgreSQL, the number of active queries can significantly impact responsiveness. This article explores a PostgreSQL query that effectively counts active queries, aiding in performance monitoring and potential scaling decisions.

Sample Code from Command Line

1SELECT
2 COUNT(*) AS active_query_count
3FROM
4 pg_stat_activity
5WHERE
6 state = 'active';

Notes: If COUNT consistently > CPU Cores, then upgrade/scale. Requires PostgreSQL >= 9.2 for state column in pg_stat_activity. Tested on PostgreSQL 9.2+, 10.x, 11.x, 12.x, 13.0

Identify Blocking PostgreSQL Queries with pg_stat_activity

Thu, 21 Mar 2024 00:00:00 +0000

Identifying Blocking Queries in PostgreSQL: Keeping Your Database Running Smoothly

Have you ever encountered sluggish performance in your PostgreSQL database? One culprit could be blocking queries. These are queries that are waiting on resources held by other queries, creating a chain reaction that slows everything down. Identifying and resolving blocking queries is crucial for maintaining optimal database health.

This article dives into a powerful PostgreSQL query that helps pinpoint bottlenecks.

PostgreSQL Backend Connections via pg_stat_database

Wed, 20 Mar 2024 00:00:00 +0000

Database Connections: A Look at PostgreSQL Backends

This article delves into a PostgreSQL code snippet that sheds light on the number of backend connections established for each database within a PostgreSQL instance. We'll dissect the code, explore its purpose, and glean valuable insights for database administrators and developers.

Sample Code from Command Line

1SELECT
2 datname,
3 numbackends
4FROM
5 pg_catalog.pg_stat_database
6ORDER BY
7 numbackends DESC,
8 datname ASC;

Notes: PostgreSQL number of backends connected to each database. Tested on PostgreSQL 8.4, 9.x, 10.x, 11.x, 12.x, 13.0.

How Many Connections Can Your PostgreSQL Database Handle?

Mon, 18 Mar 2024 00:00:00 +0000

How Many Connections Can Your PostgreSQL Database Handle?

Understanding the maximum number of connections your PostgreSQL database can accommodate is crucial for optimal performance and preventing bottlenecks. This post dives deep into the SHOW max_connections command, explaining its purpose, breakdown, and key insights to empower you with database connection management expertise.

Sample Code

1SHOW max_connections;

Purpose:

The SHOW max_connections command serves as a vital tool for retrieving the current maximum number of concurrent connections allowed for your PostgreSQL database server. These connections represent established channels between applications and the database, facilitating data exchange.

How to Monitor PostgreSQL Index Cache for High Speed Queries

Mon, 18 Mar 2024 00:00:00 +0000

Keeping PostgreSQL Queries Speeding Along: Monitoring Index Cache Hit Rates

For a smooth-running PostgreSQL database, ensuring efficient access to frequently used data is crucial. Indexes act as shortcuts, speeding up queries. But how well are those indexes utilized? This post explores a SQL query that helps you monitor the PostgreSQL index cache hit rate, offering valuable insights into your database's performance.

Sample Code

1SELECT sum(idx_blks_read) as idx_read,
2 sum(idx_blks_hit) as idx_hit,
3 (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as ratio
4FROM pg_statio_user_indexes;

Understanding the Code:

Import Data into PostgreSQL A Seamless Approach with psql

Mon, 18 Mar 2024 00:00:00 +0000

Importing Data into an Existing PostgreSQL Database

Managing your PostgreSQL database often involves importing data from backups or external sources. This post explores a simple yet effective command-line approach to achieve this: psql -d anexistingdb -f dump.sql. We'll break down its components, explain its functionality, and offer valuable insights for successful data import.

Sample Code from Command Line

1$ psql -d anexistingdb -f dump.sql

Purpose:

Backing Up a Remote PostgreSQL Database with pg_dump

Sun, 17 Mar 2024 00:00:00 +0000

Backing Up Your Remote PostgreSQL Database: A Step-by-Step Guide with pg_dump

In the world of databases, regular backups are crucial for ensuring data safety and minimizing downtime during unforeseen circumstances. This post dives into using pg_dump, a powerful PostgreSQL utility, to create a compressed archive of your remote database for safekeeping. We'll break down the code, explain its purpose, and offer valuable insights for a smooth backup process.

Sample Code from Command Line

1$ pg_dump -U username -h hostname databasename > dump.sql

Understanding the Code:

Identify Large PostgreSQL Indexes for Optimization

Sun, 17 Mar 2024 00:00:00 +0000

Unveiling Your PostgreSQL Indexes: A Deep Dive with Code

In the realm of relational databases, efficient data retrieval is paramount. PostgreSQL achieves this partly through the magic of indexes. But have you ever wondered what lurks beneath the surface of these indexes? This post delves into a powerful Postgres Database code snippet that empowers you to unlock the secrets hidden within your indexes.

Sample Code

 1SELECT n.nspname AS schemaname,
 2 c.relname AS tablename,
 3 i.relname AS indexname,
 4 t.spcname AS tablespace,
 5 pg_get_indexdef(i.oid) AS indexdef,
 6 pg_size_pretty(pg_total_relation_size(i.oid)) AS index_size
 7FROM pg_index x
 8 JOIN pg_class c ON c.oid = x.indrelid
 9 JOIN pg_class i ON i.oid = x.indexrelid
10 LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
11 LEFT JOIN pg_tablespace t ON t.oid = i.reltablespace
12WHERE (c.relkind = ANY (ARRAY['r'::"char", 'm'::"char", 'p'::"char"]))
13 AND (i.relkind = ANY (ARRAY['i'::"char", 'I'::"char"]))
14 order by index_size asc;

Unveiling Your PostgreSQL Indexes: A Deep Dive with Code

Monitor PostgreSQL Index Usage for Speedy Queries

Sun, 17 Mar 2024 00:00:00 +0000

Monitoring PostgreSQL Index Usage: Keeping Your Queries Speedy

In the fast-paced world of web applications, ensuring efficient database queries is paramount. PostgreSQL's powerful indexing capabilities play a crucial role in achieving optimal performance. This post delves into a SQL query that helps you monitor index usage rates and identify areas for potential optimization.

The Table Index Usage Rates Should not be less than 0.99