Re: A concurrent VACUUM FULL?

On Mon, Jun 30, 2025 at 1:46 PM Álvaro Herrera wrote: > On 2025-Jun-30, Erik Nordström wrote: > > > On Mon, Jun 30, 2025 at 12:03 PM Antonin Houska wrote: > > > > Patch [1] is in the queue that allows both reads and writes. (An > exclusive > > > lock is a

Re: A concurrent VACUUM FULL?

On Mon, Jun 30, 2025 at 12:03 PM Antonin Houska wrote: > Erik Nordström wrote: > > > Hi hackers, > > > > I've been looking at the code for CLUSTER/VACUUM FULL, and whether it is > possible to do a concurrent version of it using a > > multi-transactional app

A concurrent VACUUM FULL?

Hi hackers, I've been looking at the code for CLUSTER/VACUUM FULL, and whether it is possible to do a concurrent version of it using a multi-transactional approach similar to concurrent reindexing and partition detach. The idea would be to hold weaker locks in TX1 when doing the heap rewrite (ess

Re: Relstats after VACUUM FULL and CLUSTER

Hi Sami, Your patch should correct the problem. However, given that this function is part of the tableam API, I am wondering if the fix shouldn't be outside heap's copy_for_cluster implementation? I guess it depends on the semantics of num_tuples, but the cluster code seems to allude to interpreti

Re: Relstats after VACUUM FULL and CLUSTER

Hi Sami, You need a concurrent transaction to recreate the situation. I am attaching an isolation test to show the behavior, along with its output file. I ran it on PostgreSQL 17.4. The test has two permutations, the first one runs on a table without an index and the second permutation with an in

Relstats after VACUUM FULL and CLUSTER

Hi all, I noticed a potential issue with the heap cluster code used by VACUUM FULL and CLUSTER, but I am not sure so I thought I'd post the question to the list. The code in question counts the number of tuples it processes and uses that count to update reltuples in pg_class. However, the tuple c

Re: Changed behavior in rewriteheap

On Fri, Nov 22, 2024 at 3:53 PM Heikki Linnakangas wrote: > On 22/11/2024 15:56, Erik Nordström wrote: > > Yes, it solves the issue so it looks good. > > > > Just a minor nit: the code uses both blokno as local variable for > > pending_writes[i].blkno and directly

Re: Changed behavior in rewriteheap

On Fri, Nov 22, 2024 at 2:26 PM Heikki Linnakangas wrote: > On 22/11/2024 15:02, Matthias van de Meent wrote: > > I think I'd go with a patch like attached, where the bulk writer > > registers that it started with .relsize pages in the relfork, and use > > that for smgrextend() decisions. It now

Re: Changed behavior in rewriteheap

On Fri, Nov 22, 2024 at 12:30 AM Matthias van de Meent < boekewurm+postg...@gmail.com> wrote: > On Thu, 21 Nov 2024, 17:18 Erik Nordström, wrote: > >> Hello, >> >> I've noticed a change in behavior of the heap rewrite functionality in >> Postgre

Changed behavior in rewriteheap

Hello, I've noticed a change in behavior of the heap rewrite functionality in PostgreSQL 17, used by, e.g., CLUSTER. I've been experimenting with the functionality to implement a way to merge partitions in TimescaleDB. I am using table_relation_copy_for_cluster() to write the data of several table

Missing Group Key in grouped aggregate

Hello, I noticed that, beginning with PG16, grouped aggregates are missing the "Group Key" in the EXPLAIN output. It seems the Agg node has numCols (number of grouping cols) set to zero in queries like SELECT foo, count(*) FROM bar WHERE foo=1 GROUP BY foo; In PG15, the "Group Key" is shown and

Re: Feedback on table expansion hook (including patch)

rites: > > > On 07.05.20 10:11, Erik Nordström wrote: > > >> I am looking for feedback on the possibility of adding a table > expansion > > >> hook to PostgreSQL (see attached patch). > > > > > Unlike the get_relation_info_hook, your proposed hoo

Feedback on table expansion hook (including patch)

Hi, I am looking for feedback on the possibility of adding a table expansion hook to PostgreSQL (see attached patch). The motivation for this is to allow extensions to optimize table expansion. In particular, TimescaleDB does its own table expansion in order to apply a number of optimizations, inc

Re: Missing hook for UPPERREL_PARTIAL_GROUP_AGG rels?

Thanks for the quick response. I do think this might be a separate issue because in the set_rel_pathlist_hook case, that hook is actually called at one point. In this case there is simply no place in the PostgreSQL code where a call is made to create_upper_paths_hook for the UPPERREL_PARTIAL_GROUP_

Missing hook for UPPERREL_PARTIAL_GROUP_AGG rels?

Hi, I noticed that the create_upper_paths_hook is never called for partially grouped rels. Is this intentional or a bug? Only the FDW routine's GetForeignUpperPaths hook is called for partially grouped rels. This seems odd since the regular create_upper_paths_hook gets called for all other upper r