Re: Adding REPACK [concurrently]

From: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>
Cc: David Klika <david(dot)klika(at)atlas(dot)cz>, ah(at)cybertec(dot)at, jian(dot)universality(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, mihailnikalayeu(at)gmail(dot)com, rob(at)xzilla(dot)net
Subject: Re: Adding REPACK [concurrently]
Date: 2025-12-06 10:58:36
Message-ID: 202512041802.gzsr3v644a5l@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

On 2025-Dec-04, Marcos Pegoraro wrote:

> Em qui., 4 de dez. de 2025 às 12:43, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> escreveu:
>
> > So if you're trying to do this, the number of problematic pages must
> > be large.
>
> Not necessarily. I have some tables where I like to use CLUSTER every
> 2 or 3 months, to reorganize the data based on an index and
> consequently load fewer pages with each call. These tables don't have
> more than 2 or 3% of dead records, but they are quite disorganized
> from the point of view of that index, since the inserted and updated
> records don't follow the order I determined.

I don't understand what does this have to do with what David was
proposing. I mean, you're right: if all you want is to CLUSTER, you may
not have an enormous number of pages to get rid of. But how can you use
the technique he proposes to deal with reordering tuples? If you just
move the tuples from the end of the table to where some random hole has
appeared, you've not clustered the table at all.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"People get annoyed when you try to debug them." (Larry Wall)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2025-12-06 11:22:37 Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Previous Message Álvaro Herrera 2025-12-06 10:53:50 Re: IPC/MultixactCreation on the Standby server