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?
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.
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.
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…
On 14th of December 2025, Alexander Korotkov committed patch:
Implement ALTER TABLE ... MERGE PARTITIONS ... command This new DDL command merges several partitions into a single partition of the target table. The target partition is created using the new createPartitionTable() function with the parent partition as the template. This commit comprises a quite naive implementation which works in a single process and holds the ACCESS EXCLUSIVE LOCK on the parent table during all the operations, including the tuple routing. This is why this new DDL command can't be recommended for large partitioned tables under a high load. However, this implementation comes in handy in certain cases, even as it is. Also, it could serve as a foundation for future implementations with less locking and possibly parallelism. Discussion: https://postgr.es/m/c73a1746-0cd0-6bdd-6b23-3ae0b7c0c582%40postgrespro.ru Author: Dmitry Koval <d.koval@postgrespro.ru> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Co-authored-by: Tender Wang <tndrwang@gmail.com> Co-authored-by: Richard Guo <guofenglinux@gmail.com> Co-authored-by: Dagfinn Ilmari Mannsaker <ilmari@ilmari.org> Co-authored-by: Fujii Masao <masao.fujii@gmail.com> Co-authored-by: Jian He <jian.universality@gmail.com> Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com> Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Robert Haas <rhaas@postgresql.org> Reviewed-by: Stephane Tachoires <stephane.tachoires@gmail.com> Reviewed-by: Jian He <jian.universality@gmail.com> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Daniel Gustafsson <dgustafsson@postgresql.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Noah Misch <noah@leadboat.com>
and then, mere seconds later, he also committed second patch:
Implement ALTER TABLE ... SPLIT PARTITION ... command This new DDL command splits a single partition into several partitions. Just like the ALTER TABLE ... MERGE PARTITIONS ... command, new partitions are created using the createPartitionTable() function with the parent partition as the template. This commit comprises a quite naive implementation which works in a single process and holds the ACCESS EXCLUSIVE LOCK on the parent table during all the operations, including the tuple routing. This is why the new DDL command can't be recommended for large, partitioned tables under high load. However, this implementation comes in handy in certain cases, even as it is. Also, it could serve as a foundation for future implementations with less locking and possibly parallelism. Discussion: https://postgr.es/m/c73a1746-0cd0-6bdd-6b23-3ae0b7c0c582%40postgrespro.ru Author: Dmitry Koval <d.koval@postgrespro.ru> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Co-authored-by: Tender Wang <tndrwang@gmail.com> Co-authored-by: Richard Guo <guofenglinux@gmail.com> Co-authored-by: Dagfinn Ilmari Mannsaker <ilmari@ilmari.org> Co-authored-by: Fujii Masao <masao.fujii@gmail.com> Co-authored-by: Jian He <jian.universality@gmail.com> Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com> Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-by: Zhihong Yu <zyu@yugabyte.com> Reviewed-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Robert Haas <rhaas@postgresql.org> Reviewed-by: Stephane Tachoires <stephane.tachoires@gmail.com> Reviewed-by: Jian He <jian.universality@gmail.com> Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reviewed-by: Daniel Gustafsson <dgustafsson@postgresql.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Noah Misch <noah@leadboat.com>