Re: BRIN index maintenance on table without primary key

From: Dimitrios Apostolou <jimis(at)gmx(dot)net>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: BRIN index maintenance on table without primary key
Date: 2023-10-30 12:20:01
Message-ID: 4f0c1fab-eb42-a036-0e45-1de202527ea6@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 27 Oct 2023, Dimitrios Apostolou wrote:

> So the question is: how to maintain the physical order of the tuples?

Answering to myself, there doesn't seem to be any way to run pg_repack on
a table without a UNIQUE key.

To run CLUSTER, the only way I see is to:

1. Create a btree index on the same column that has the BRIN index
2. CLUSTER
3. Drop the index

This should take very long on my huge table, and keeps the table
exclusively locked. The disk space needed would also be huge, if the table
isn't partitioned.

I wonder why CLUSTER can't run based on a BRIN-indexed column. Is it
theoretically impossible, or is it just not implemented yet?

My understanding so far is that CLUSTER only rewrites the table *according
to the index order* and does not touch the index itself. For a BRIN index
though it would need to rewrite the table *ignoring the index* and then
rewrite the index too, in order to keep the ranges fully optimized. So the
logic is very different, and maybe closer to what VACUUM FULL does.

Thanks,
Dimitris

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Luca Ferrari 2023-10-30 12:44:22 xmax not zero?
Previous Message yangsr3411 2023-10-30 11:07:07 Fw: Server process exited with exit code 4