select * from depesz;

Waiting for PostgreSQL 19 – Introduce the REPACK command

On 10th of March 2026, Álvaro Herrera committed patch:

Introduce the REPACK command
 
REPACK absorbs the functionality of VACUUM FULL and CLUSTER in a single
command.  Because this functionality is completely different from
regular VACUUM, having it separate from VACUUM makes it easier for users
to understand; as for CLUSTER, the term is heavily overloaded in the
IT world and even in Postgres itself, so it's good that we can avoid it.
 
We retain those older commands, but de-emphasize them in the
documentation, in favor of REPACK; the difference between VACUUM FULL
and CLUSTER (namely, the fact that tuples are written in a specific
ordering) is neatly absorbed as two different modes of REPACK.
 
This allows us to introduce further functionality in the future that
works regardless of whether an ordering is being applied, such as (and
especially) a concurrent mode.
 
Author: Antonin Houska <ah@cybertec.at>
Reviewed-by: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Reviewed-by: Álvaro Herrera <alvherre@kurilemu.de>
Reviewed-by: Robert Treat <rob@xzilla.net>
Reviewed-by: Euler Taveira <euler@eulerto.com>
Reviewed-by: Matheus Alcantara <matheusssilv97@gmail.com>
Reviewed-by: Junwang Zhao <zhjwpku@gmail.com>
Reviewed-by: jian he <jian.universality@gmail.com>
Discussion: https://postgr.es/m/82651.1720540558@antos
Discussion: https://postgr.es/m/202507262156.sb455angijk6@alvherre.pgsql

Continue reading Waiting for PostgreSQL 19 – Introduce the REPACK command

Waiting for PostgreSQL 19 – Allow table exclusions in publications via EXCEPT TABLE.

On 4th of March 2026, Amit Kapila committed patch:

Allow table exclusions in publications via EXCEPT TABLE.
 
Extend CREATE PUBLICATION ... FOR ALL TABLES to support the EXCEPT TABLE
syntax. This allows one or more tables to be excluded. The publisher will
not send the data of excluded tables to the subscriber.
 
To support this, pg_publication_rel now includes a prexcept column to flag
excluded relations. For partitioned tables, the exclusion is applied at
the root level; specifying a root table excludes all current and future
partitions in that tree.
 
Follow-up work will implement ALTER PUBLICATION support for managing these
exclusions.
 
Author: vignesh C <vignesh21@gmail.com>
Author: Shlok Kyal <shlok.kyal.oss@gmail.com>
Reviewed-by: shveta malik <shveta.malik@gmail.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Reviewed-by: Peter Smith <smithpb2250@gmail.com>
Reviewed-by: Dilip Kumar <dilipbalaut@gmail.com>
Reviewed-by: Zhijie Hou <houzj.fnst@fujitsu.com>
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>
Reviewed-by: David G. Johnston <david.g.johnston@gmail.com>
Reviewed-by: Ashutosh Sharma <ashu.coek88@gmail.com>
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Andrei Lepikhov <lepihov@gmail.com>
Discussion: https://postgr.es/m/CALDaNm3=JrucjhiiwsYQw5-PGtBHFONa6F7hhWCXMsGvh=tamA@mail.gmail.com

Continue reading Waiting for PostgreSQL 19 – Allow table exclusions in publications via EXCEPT TABLE.

Waiting for PostgreSQL 19 – Add non-text output formats to pg_dumpall

On 26th of February 2026, Andrew Dunstan committed patch:

Add non-text output formats to pg_dumpall
 
pg_dumpall can now produce output in custom, directory, or tar formats
in addition to plain text SQL scripts. When using non-text formats,
pg_dumpall creates a directory containing:
- toc.glo: global data (roles and tablespaces) in custom format
- map.dat: mapping between database OIDs and names
- databases/: subdirectory with per-database archives named by OID
 
pg_restore is extended to handle these pg_dumpall archives, restoring
globals and then each database. The --globals-only option can be used
to restore only the global objects.
 
This enables parallel restore of pg_dumpall output and selective
restoration of individual databases from a cluster-wide backup.
 
Author: Mahendra Singh Thalor <mahi6run@gmail.com>
Co-Author: Andrew Dunstan <andrew@dunslane.net>
Reviewed-By: Tushar Ahuja <tushar.ahuja@enterprisedb.com>
Reviewed-By: Jian He <jian.universality@gmail.com>
Reviewed-By: Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com>
Reviewed-By: Srinath Reddy <srinath2133@gmail.com>
Discussion: https://postgr.es/m/cb103623-8ee6-4ba5-a2c9-f32e3a4933fa@dunslane.net

Continue reading Waiting for PostgreSQL 19 – Add non-text output formats to pg_dumpall

Waiting for PostgreSQL 19 – Allow log_min_messages to be set per process type

On 9th of February 2026, Álvaro Herrera committed patch:

Allow log_min_messages to be set per process type
 
Change log_min_messages from being a single element to a comma-separated
list of type:level elements, with 'type' representing a process type,
and 'level' being a log level to use for that type of process.  The list
must also have a freestanding level specification which is used for
process types not listed, which convenientely makes the whole thing
backwards-compatible.
 
Some choices made here could be contested; for instance, we use the
process type `backend` to affect regular backends as well as dead-end
backends and the standalone backend, and `autovacuum` means both the
launcher and the workers.  I think it's largely sensible though, and it
can easily be tweaked if desired.
 
Author: Euler Taveira <euler@eulerto.com>
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Japin Li <japinli@hotmail.com>
Reviewed-by: Tan Yang <332696245@qq.com>
Discussion: https://postgr.es/m/e85c6671-1600-4112-8887-f97a8a5d07b2@app.fastmail.com

Continue reading Waiting for PostgreSQL 19 – Allow log_min_messages to be set per process type

Waiting for PostgreSQL 19 – psql: Add %i prompt escape to indicate hot standby status.

On 3rd of February 2026, Fujii Masao committed patch:

psql: Add %i prompt escape to indicate hot standby status.
 
This commit introduces a new prompt escape %i for psql, which shows
whether the connected server is operating in hot standby mode. It
expands to standby if the server reports in_hot_standby = on, and
primary otherwise.
 
This is useful for distinguishing standby servers from primary ones
at a glance, especially when working with multiple connections in
replicated environments where libpq's multi-host connection strings
are used.
 
Author: Jim Jones <jim.jones@uni-muenster.de>
Reviewed-by: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Greg Sabino Mullane <htamfids@gmail.com>
Reviewed-by: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Reviewed-by: Nathan Bossart <nathandbossart@gmail.com>
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Andreas Karlsson <andreas@proxel.se>
Discussion: https://www.postgresql.org/message-id/flat/016f6738-f9a9-4e98-bb5a-e1e4b9591d46@uni-muenster.de

Continue reading Waiting for PostgreSQL 19 – psql: Add %i prompt escape to indicate hot standby status.

Per-worker, and global, IO bandwidth in explain plans

Jeremy Schneider suggested a change to how plans are displayed – adding another bit of information in case we have timing information for IO for explain node. Took me a while to research, but it finally made it's way…

Continue reading Per-worker, and global, IO bandwidth in explain plans

How to render timestamp with a timezone that is different from current?

This question appeared on IRC, and while I wasn't there while it happened, it caught my eye:

» Can I not render this with timezone offset: select ‘2026-01-09 04:35:46.9824-08'::timestamp with time zone at time zone ‘UTC';
» Returns ‘2026-01-09 12:35:46.9824' which is without the offset.

Continue reading How to render timestamp with a timezone that is different from current?

Quick and dirty loading of CSV files

Back in September 2025, David Fetter asked on IRC, about a tool to quickly load CSV to database. One that would require minimal configuration, will try to figure out as much as possible on its own.

I thought that it would be great idea. Plus, I'm trying to learn more JavaScript / Node, so figured I can try.

Work and life intervened, and I couldn't get to it.

In the mean time I also read a lot of praise for some AI tools for quickly starting projects, or adding functionality, or learning new stuff. So, I decided to try.

Used Claude to make the basics, and then worked to add more tests and functionality.

Long story short, the tool is here.

It does what David wanted – works as simply as possible. Assuming you have your environment configured, you can just:

=$ pg_csv_loader some_file.csv

And it will figure out delimiter, quote character, column names, datatypes, and will load it to default database – which works just like normal psql

Tested it on couple different csv files, and it seems to work. It also handled PostgreSQL csv logs, which are often problematic as they use literal new line characters, which is causing problems for some parsers.

I don't claim that I wrote it, but I did extend tests, and datatype detection, so I guess I have some partial credit 🙂

Hope you'll find it useful.

Small improvement for pretty-printing in paste.depesz.com

As you maybe know, some time ago I made paste service, mostly to use for queries, or related text to share on IRC.

One part of it is that it also has pretty printer of provided queries.

Recently I realized that in case of complex join conditions, the output is, well, sub-optimal. For example:

SELECT
    t1.a,
    t2.b,
    t3.c
FROM
    table_1 AS t1
    JOIN table_2 AS t2 ON t1.x = t2.x AND
    t1.y = t2.y AND
    t1.z = t2.z
    LEFT JOIN table_3 AS t3 ON t1.f = t3.f AND
    t2.g = t3.g
WHERE
    t1.v = 1 AND
    t2.t = 'x' AND
    t3.m < 123

Specifically the problem (for me) is bad indentation of join conditions (aside from first).

Anyway – as of now, the same query will be pretty-printed as:

SELECT
    t1.a,
    t2.b,
    t3.c
FROM
    table_1 AS t1
    JOIN table_2 AS t2 ON t1.x = t2.x
        AND t1.y = t2.y
        AND t1.z = t2.z
    LEFT JOIN table_3 AS t3 ON t1.f = t3.f
        AND t2.g = t3.g
WHERE
    t1.v = 1
    AND t2.t = 'x'
    AND t3.m < 123

Also, as a reminder – you can use this pretty printer from command line or some tools, without storing anything on paste.depesz.com site – simply use script that I described earlier.

Hope you'll find it useful.

What is index overhead on writes?

One of things people learn is that adding indexes isn't free. All write operations (insert, update, delete) will be slower – well, they have to update index.

But realistically – how much slower?

Full tests should involve lots of operations, on realistic data, but I just wanted to see some basic info. So I figured I'll just look at speed of inserting data (well, COPYing data), and will try to extract some knowledge from it…

Continue reading What is index overhead on writes?