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
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 |