The release is planned for September 2026, though it’s time to go through the new features and changes.
All three features below are cool and great developments from the authors of the patches that implemented them. But there are a lot of new cool features and extesnions to exisiting features done by a lot of people.
My thanks go out to all the people who made PostgreSQL 19 possible.
For all others there is still the opportunity to be part of that people, your time is now to test the current and comming beta and release candidates of PostgreSQL 19. And please report bugs you may find.
That way you help all users having a stable release version ready to use in production.
The INSERT became a new conflict action: It can now return a SELECT for conflicts.
Previously it already hat the options DO NOTHING and DO UPDATE, the first one did exactly what it was named, doing nothing, the second on offered to update the already existing columns.
The SELECT gives a complete new set of possibilities to handle existing data in an INSERT statement.
Previously one needed an extension, pg_repack, but repack is now a command directly availabe in PostgeSQL 19.
Not only is it now a command, it also supports the parameter CONCURRENTLY. That way repack does not affect current database sessions.
And you can pass an index name of an existing index to sort the repacked table after an index. When you have defined the sortorder with CLUSTER and you do not pass an index name, the sortorder is done after the index specified in CLUSTER.
That does obviously not solve the problem of having the table data always physically sorted, but at least with REPACK as regular maintenance job, the data is mostly sorted.
Graph Query Language (GQL) is a standardized query language for property graphs.
SQL/PGQ is the SQL standard extension to add the Graph Query Language to relatianonal databases.
It is availabe now in PostgeSQL, too, please see the Property Graphs documentation.
]]>Yesterday the maintainer of PgBackRest, David Steele, published the NOTICE OF OBSOLESCENCE.
For further information please read the blog post pgBackRest is dead. Now what? by Lætitia Avrot. She also points to how to go an as she, like me, always recommended PgBackRest for PostgreSQL backups.
Therefore a big thank you goes for the work David has done on PgBackRest.
Things alike happened before, for example when due to the liquidation of the Segfault Inc. Multicorn became an abandend project.
That has been solved by several people creating a fork and named that fork Multicorn2.
I predict that very soon several forks of PgBackRest will be spotted in the wild with different names. And that might become a problem.
It might end up with different patches solving problems and they would not be consistent. In additon, which fork would become the replacement the RPM or DEB packages?
This would also not solve the problem, that a very good maintainer of an essential part of the PostgreSQL ecosystem does not get paid for the work he’s done. And keep in mind, that this is not a small job that one could do as a side project. He, like all of us, needs to make a living.
Even having a another company sponsoring him would only be a short-time solution. What when that company get bought, or a new CEO decides to spare the money to invest it elsewhere?
Some people of the PostgreSQL community already thought, that it might be a good idea to move PgBackRest into PostgreSQL itself.
But that might also be a short-time solution, in additon to all the arguments speaking against this way like, the code differs a lot to PostgreSQL standards.
What about other widely used projects in the PostgreSQL ecosystem that are widely used, and extenesions, that do have a lot of users?
IMHO an umbrella organisation for tools in the PostgreSQL ecosystem would be a good solution. No single company owning the code. Also switching maintainers would be much easier.
Not to speak about that it would be much easier to raise money by an organisation, than some single persons trying to raise enough for an income for themselves.
There are already examples out there that might help to find a solution. To mind are coming The Apache Software Foundation and Codeberg e.V..
I know that someone has already submitted a proposal for the PostgreSQL Conference Europe Community Event Day, but that conference is about six months away. Nevertheless, it would be a good place to discuss stuff in person.
Feel free to contact me to discuss what think about my ideas per email or on Telegram.
]]>The sparql_fdw is a foreign data wrapper to connect to query web databases with the SPARQL protocol from inside PostgreSQL written in Python.
As multicorn2 is already working with PostgreSQL 18, I tested the sparql_fdw, too.
It worked like a charm and I have added PostgreSQL 18 to the supported versions in the README file.
In addtion I removed PostgreSQL 12 as supported version as that version is out of support.
]]>A lot of settings and also the database design do have an impact of the performance of a PostgreSQL database.
PostgreSQL does not create an index when a foreign key is created. This might seem as a downside, but it is not. It gives the database designers the opportunity create that index with a different index type than the referenced table is using.
An example is on a big table a block range index (BRIN) will be faster and kept in memory compared to a B-Tree index.
My PostgreSQL extension pgsql_tweaks has a view for that: Documentation of pg_foreign_keys.
Check execution plans, use EXPLAIN ANALYSE to find them while developing. To find them in production use the missing indexes view from pgsql_tweaks.
There need to be some data in the database, otherwise PostgreSQL uses wrong assumptions.
Also install the auto_explain extension to get runtime execution plans for slow queries.
Having too many indexes does slow down INSERT and UPDATE statements. Indexes have to written to disk.
Use multicolumn indexes, indexes on expressions, and/or partial indexes (yes, indexes can have a where condition) .
Conditional indexes are great for example when tables do contain records, that are marked in a column as deleted. When someone needs to access the deleted records, a query takes longer because not deleted can be a condition in an index. But the active records can be found much faster as the index is much smaller and might easier stay in memory and there aren’t that many pages to parse in a tree.
Regularly check for unused indexes especially on the production database.
pgsql_tweaks has a view for that: pg_unused_indexes.
Too many users connecting to PostgreSQL is not something, PostgreSQL is good in.
That is due to how a connection is done. For every connection postgres process is forked into a new one.
This can end up in not being able to copy a new process and the database connection fails.
Also with a lot of connections each connection will only have a small amount of RAM available. That results into writing stuff to disk into the cache. Even while mostly the spinning rust is gone, this will slow down the answer.
Use a server side connection pooler like PgBouncer to increase the amount of connections. It does keep connections open and spares PostgreSQL to copy processes for every new connection.
Another problem might even end in a immediate server shutdown. When the configuration is not well calculated, PostgreSQL might run out of memory.
On heavy writing PostgreSQL servers it is often usefull to have disks for certain purposes. This splitts the work of writing data.
Just to have several partitions on the same disk does not speed anything up.
Splitting data over disks and using ZFS doing snapshots is impossible, as the time will differ between the different disks.
This results in an inconsistent state for a RDBMS and PostgreSQL will fail to start as it has several check functions that take care, that the system is not in an undefined status.
Insufficient network problems can be very problematic. And that is not only true for the client connection, but also for the replication of data.
This could result in followers falling behind of the primary. Which is resulting in wrong query results on a follower compared to the same query on the primary.
But there is also a problem, when the follower is not able to get the WAL from the primary.
This could result in a full disk and that will end with PostgreSQL shutting down.
Monitor the primary and the followers about the WAL status, use the view stats.replication.
PostgreSQL Vacuum is necessary to remove data from tables, that is not visible anymore. This is due to how Multi Version Concurrency Control (MVCC) is implemented.
Autocacuum takes care of removing the unvisible data by making the space availabe for reusage. This does not result in more free disk space. Except when pages that are located at the end of a table are vacuumed. These pages will be removed.
Statistically speaking, that can be ignored.
Therefore never turn autovacuum off.
By default autovacuum is configured very conservative. The setting can be adjusted to be more aggressive, meaning to clean up less bloated tables and having more workers, espescially when there are lots of tables.
Parameters to tune:
The autovacuum_max_workers has to be adjusted to the other jobs running on the server. Meaning, that too many of these workers might slow down the server.
On tables where lots of UPDATE and/or DELETE are executed against, autovacuum can be adjusted to run more often than what is set in the global configuration.
This results in shorter runtimes of autovacuum on this tables, therefore reducing the impact.
To know bloat of tables, the ones with high inserts, updates, and/or deletes should be monitored.</br />
Don’t monitor all tables, that will move the focus away from what is neccessary to monitor.
There is a view to see the current status of tables, pg_table_bloat. This view is very expensive, therefore do not execute it too often. It is often usefull to filter tables to only those, that do need monitoring.
The downside with TimescaleDB here is, that all time partitions are independend tables for PostgreSQL, therefore you cannot not just monitor the main TimescaleDB table. In fact exclude them, as they do not return any goodinformation.
Index only scans are the fastest way to access data in joins, where conditions, and sorting.
-- Tuning autovacuum for index only scans
ALTER TABLE {table name}
SET (autovacuum_vacuum_scale_factor = 0.01)
;
With having 100,000 transactions per day doing UPDATE or DELETE, tune it to run round about once a day.
Adjust autovacuum_freeze_max_age to the number of daily transactions on these tables.
ALTER TABLE {table name}
SET (autovacuum_freeze_max_age = 100000)
;
Transaction Wraparound is a serious problem that even might take server maintenance downtime if not addressed.
Anti-Wraparound vacuum has to be able to freeze tuples in all tables.
Blocking anti-wraparound can be coused by:
For tables with lots of INSERT statements the problem is solved with Autovacuum High Inserting Into Tables.
Fillfactor is availabe on tables and indexes.
PostgreSQL stores its data in pages. The fillfactor affects the size of the page that is filled in percent.
The fillfactor increases the performance especially of UPDATE statements.
The rule of thumb is to have a fillfactor on tables between 70 % and 90%, depending on the amount of updates and the size of a row stored in a page.
On tables that get rows only inserted, a fillfactor of 100 % is the best setting.
The fillfactor affects indexes differently than tables. B-Tree indexes get new leaves on the same page, when possible, otherwise a page is split and the index is splitted over several pages.
Therefore the fillfactor is usefull for INSERT and UPDATE statements on indexes.
The more data you have, the more memory your servers will have. Accessing the data in RAM still is magnitutes faster than grabbing them from SSDs, not to speak about rotating disks.
Every time you have to restart a PostgreSQL server, the caches are empty and will be filled again step by step. But that is not a greate experience for users as their requests run slow because their data has to be grabbed from disk.
There is an extension to solve this problem: pg_prewarm.
When a server is shut down, it takes a bit longer as the data in chaches will be written to disk. Also the start is slower as the caches will be filled with the content of the file on disks. But the user experience is the same as before.
]]>The idea of the logo is based on a citation of David E. Wheeler. He once said, that this extension is sort of my PostgreSQL swiss army knife.
When I asked the designer of the logo, (Elodie Jex)[], to create a logo, she wanted some contexts. I explained PostgreSQL and extensions a bit. In addition I told her the swiss army knife story.
She used that information to come up with the shiny new logo for the pgsql_tweaks extension.
]]>The source code is available on Codeberg.
You can install the whole package, or just copy what is needed from the source code.
The extension is also available on PGXN.
I decided to make this the 1.0 Version. The First commit is from 2017-08-11, the extension is now more than eight years old.
The project started as a personal repository. When I left GitHub, see Leaving GitHub and GitHub is History for details, I decided to move it to a project on its own on Codeberg.
The website on pgsql-tweaks.org has been setup first with the HTML help page of the project.
Now it is a real website realised with Jekyll. Future changes of pgsql_tweaks will be blogged on pgsql-tweaks.org/blog.
The source code is part of the project on Codeberg.
Also the documentation has been changed from a single Markdown file to a website, also realised with Jekyll on rtfm.pgsql-tweaks.org. RTFM stands for Read The Fine Manual.
The source code is part of the project on Codeberg.
This move also opens the possibilities to contribute to the project. The documentation has now detailed information about how to contribute:
Thanks to Elodie Jex the extension has a shiny logo.
Instead of the current default schema, the extension is now created in its own schema. This solves conflicts with other extensions, as has been the case in the past with pgtap, see pgTAP Issue 340 for details.
The view has not been documented in previous versions.
The new features are blogged on pgsql_tweaks Version 1 Released!.
]]>Last month I wrote in Leaving GitHub that ProOpenSource OÜ applied for a membership of the Codeberg e.V., the public organistion, that is behind codeberg.org.
On Thursday, September 03, 2025 I got the message, that this is now official.
I am proud my company is able to support the hosting of open source repositories.
Codeberg is a non profit organistion hosting open source Git repositories.
There is no tracking and sharing personal information with third parties.
This is a big difference compared to other other Git hosters, especially to GitHub.
]]>The source code is available on Codeberg.
The extension is also available on PGXN.
The extension is also availabe through the PostgreSQL rpm packages.
No code has been changed.
The documentation of the view pg_bloat_info was the wrong one as it covered a view, that is in the making for a future version.
This is fixed in this release.
]]>The source code is available on Codeberg.
The extension is also available on PGXN.
The extension is also availabe through the PostgreSQL rpm packages.
There is only one repository for the source code of the extension, codeberg.org/pgsql_tweaks/pgsql_tweaks from now on.
The source is now part of pgsql_tweaks project.
The project has its own website, pgsql-tweaks.org. Currently the website is only a HTML copy of the HTML help page of the project.
This will be changed to a documentation website of the project, the work is already started.
The sources of the website are also part of the pgsql_tweaks project. The documentation will be based on Jekyll, please see the projects jekyll branch.
No code has been changed. Tests against PostgreSQL 18 beta 3 have been successful.
Therefore PostgreSQL 18 is now supoorted by pgsql_tweaks.
The documentation of the view pg_bloat_info has been added, the view itself has been released earlier.
]]>At least to me. Today was the day to remove all left repositories from GitHub. Afterwards I deleted my account.
You don’t need GitHub to handle your Git repositories. Git is federated and you can add remotes and/or remove them.
First their current CEO declared in an interview, that you are not a software developer, when you are not following The AI Con. I wrote about that in my blog post Leaving GitHub.
Only a week later the same guy announced he would step back from his position. And Microsoft did its best to add another nail to GitHubs coffin, they decided that it does not get a new CEO and will be integrated into their CoreAI organisation.
That move by Microsoft only affirmed my decision to leave GitHub behind. And I also decided, that I do not want to link to their AI con pages.
As a citizen of the European Union I also demanded to delete information about me from their servers, that are not releated to crucial busines data, that need to be kept.
In Europe we do have the General Data Protection Regulation (GDPR). This law gives citizen of the European Union a lot more rights how their data are allowed to be handled.
You can demand that GitHub deletes yoru personal data according to Art. 17 GDPR within one month with an email request to privacy@github.com and/or dpo@github.com.
You can do the same things as on GitHub, but so far they did not any stupid AI stuff or publish stupid things about developers who disagree with the AI slope.
I moved my personal repositories to GitLab right after Microsoft bought GitHub in 2018 and only kept mirrors on GitHub.
You can also run the GitLab community edition on your own infrastructure, it is availabe for several environments, see about.gitlab.com/install for details.
It is licensed under the MIT licencse.
When you are able to run a self hosted environment, this might be a possible solution.
Forgejo is licensed under the GNU General Public License v3.0 or later.
Codeberg is based on Forgejo. It is mantained by a public non-profit organisation that accepts donations and offers personal and company memberships to support them.
Services are offered for free and open source projects.
My company, ProOpenSource OÜ, applied for a company membership.
]]>](https://pgsql-tweaks.org/assets/img/PNG/pgsql_tweaks-logo-1-sqare.png){kind=link}