Notes from PGConf.EU 2026

Andrei Lepikhov from Conserving CPU's cycles ...Oct 31, 2026

Notes from PGConf.EU 2026

Stage talks, hallway talks, and what was left unsaid

Oct 31

PGConf.EU 2026 in Valencia was my first Postgres conference. A curious feeling: you seem to know no one, not even by face, yet as you scan the names on the badges, you realise you share common topics and old, never-resolved questions with many attendees. Damn remote work!

The days were packed, and several technical questions became clearer for me. I will pin down the most important ones here — they may come in handy for other developers who care about where the project is heading.

What was said on stage

Let me start with the talks. Every presentation is a business card, a declaration of its author's current interests. So before approaching a speaker with questions, it is worth watching their talk first. Here is what I managed to attend.

Robert Treat, REPACK in Core. It seems we have two polar approaches to table defragmentation: opportunistic cleanup of a single page and VACUUM FULL / REPACK of the whole table (and its indexes) at once. Framed this way, the next step suggests itself — defragmenting a segment of two or more adjacent pages: moving tuples closer to the beginning of the table so that, over time, the empty tail can be cut off. This may matter, because some heavily used tables simply cannot be repacked just like that.

Bertrand Drouvot, Per-Backend Statistics: See What Every Connection Is Actually Doing. The talk nudged me towards an idea. For a regular backend, statistics are naturally bound to the PID. But what about background workers? Take a logical replication worker: it may legitimately restart from time to time and carry on — that is, it inherits the context of the previous process. It would be logical to let part of its statistics keep accumulating after a restart. That would open up interesting possibilities - at the very least, counting how many times the worker has been restarted.

Heikki Linnakangas, Signals, Latches, and Interrupts. Apparently, the community is interested in rewriting the interrupt subsystem and letting extensions register their own handlers. This opens up plenty of scenarios: for example, signalling a module to refresh its private cache without extra shared memory, or interrupting a query to analyse its state halfway through.

Robert Haas, pg_plan_advice: Plan Stability and User Planner Control for PostgreSQL. After his talk, it became clearer to me why he is pushing this topic so actively. His motive is to debug and investigate queries. That is why he calmly took the questions about the risks it brings (use-after-free, for example) and about the restrictions it puts on third-party extension developers. IMO, in his world, this extension isn't for production (yet) - hence the relaxed attitude.

Melanie Plageman, Exercising PostgreSQL Performance Enhancing Patches. A talk about how patches are written and tested — in a sense, about the stages of their life. I suppose she prepared this overview mostly for herself, to reflect on the development process. For an experienced contributor, it should be fairly boring. However, one claim stood out to me: according to her, the community rarely commits patches with a regression. It would be curious to find even one significant feature that didn't bring at least one case of performance degradation.

Daniel Gustafsson, The current state of JIT in PostgreSQL. The past, present and future of JIT — fairly honest and self-critical, to my taste. The main thing is that the community understands where JIT brings real benefit: generic plans and aggregate evaluation. He is also actively working on relative addressing, without which reusing compiled code will not work. Now it comes down to resources: if the community has specialists in this exact area, now is the time to help him.

Thomas Munro, Where next for parallel query execution? The author dissected the weak spots of parallel query processing in detail. He looked really deep, although he did not try to criticise the very foundations of the current approach. He did not address parallelism for temporary tables—even though such technology has been in service for more than a year in several PostgreSQL forks built for ERP systems - see, for example, here and here.

Rafia Sabih, Unlocking Parallel Query in postgres_fdw. Quite an ordinary project, but something else matters here: the community understands the postgres_fdw limitation that forbids parallelism on the remote side of a query, and a real solution exists and is evolving. The observed regressions could be addressed with the traditional cost-based approach.

What was said in the hallways

The hallway track turned out to be as useful as the main programme.

Smart pointers for optimiser paths. This is about detecting paths that are referenced from some variant of the query plan tree. One of the planner developers confirmed that the community considers this task important. The gain is threefold: memory savings (paths nobody references can be freed as soon as the upper RelOptInfo has finished building its own paths), closing potential use-after-free bugs, and a road to more complex optimisations that span several plan levels at once. He has no time for it right now, but he is ready to support someone else’s efforts. The main problem of this project is complexity. Perhaps there is a simpler way: for example, a counter that is never decremented. Then the counter field isn't needed at all - it is enough to copy the path into a dedicated memory context on the first reference. All in all, the topic is important, and there is plenty of room for creativity.

Bloom filters in the planner. One of the committers believes the path-based approach is the one to develop: he expects it to give better quality when choosing the join tree. The main brake on the ‘opportunistic’ variant is that EXPLAIN starts showing misleading numbers, and the cost estimate looks wrong. This variant deserves a more detailed discussion on concrete examples. To my taste, it is an impractical decision — but who said OSS is about being customer-oriented?

Parallelism for temporary tables. The community is not against considering projects that pave the way for temporary tables in parallel query plans. Attempts to parallelise INSERT INTO … SELECT and similar constructs will also be studied with interest — the problem is ripe.

One more observation: several companies are building services for automated PostgreSQL tuning for a specific workload. That is great, because it signals demand. Users feel that horizontal or vertical scaling alone isn't enough, and they're looking in a more reasonable direction: using what they already have effectively. This one warms my heart in particular.

Left unsaid

Naturally, in such a short time, it was hard to cover everything. So some things remained undiscussed. I will pin them down here — what if one of the speakers reads this and replies?

The first storyline is the evolution of the I/O subsystem. Peter Geoghegan, "An Overview of Index Prefetching", and Tomas Vondra, "AIO performance — now and in the future" — talks that, from the optimiser's point of view, are about the same thing: the executor has learned to read the disk smarter. At the same time, cost estimation knows nothing about it. On the first topic, the natural question is whether the random_page_cost GUC makes sense at all for an index scan with prefetching, or whether we need a separate parameter, or even an entirely different model — not 'a page costs X', but 'a queue of depth N costs Y'. On the second — what to do with effective_io_concurrency if AIO picks the depth by itself: keep it as a hint to the planner, or remove it from the cost model altogether.

The second storyline is managing the plan from the outside. Robert Haas with pg_plan_advice and Lukas Fittl with "The Future of Plan Management and Feedback Loops". My question about advice is staleness: if we can already recommend a hint that improves a plan, it would be nice to invent the reverse—how to recommend removing a hint. Otherwise, if the advice has pinned the join order and the statistics have drifted away half a year later, who will notice — the extension, the user, or no one? For Lucas, the question is broader: isn't it time to aim higher and move from monitoring to a feedback loop in the planner (see here and here). What has changed technically, apart from pg_plan_advice appearing as an entry point?

Where things are heading

What was in the air? Where are the main interests directed? A purely subjective matter; here is what I noted for myself:

Attempts to make the DBMS core elastic — shared buffers, storage, configuration. Previously, it was more talk and prototypes; now, as developers say, this is the direction their employers actually demand.
Optimisation of the I/O stack — mostly prefetching and asynchrony.
Separation of storage and compute, and development of several data storage options at once: Google, Microsoft and Databricks. A pity these were sponsor talks, which do not go deep into technical detail, but the approaches look fundamentally different from each other. Then again, separating the physical and logical structure of a database is one of the strongest sides of relational DBMSs, isn't it?

THE END.
Madrid, Spain. 31 October 2026.