public inbox for [email protected]
help / color / mirror / Atom feedFrom: Antonin Houska <[email protected]>
To: [email protected]
Cc: Chao Li <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Fix REPACK with WITHOUT OVERLAPS replica identity indexes
Date: Tue, 12 May 2026 18:48:48 +0200
Message-ID: <70401.1778604528@localhost> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
Álvaro Herrera <[email protected]> wrote:
> On 2026-May-11, Chao Li wrote:
>
> > > On May 10, 2026, at 06:38, Álvaro Herrera <[email protected]> wrote:
>
> > > I think it would be a good idea to make identity_key_equal() not deform
> > > all attributes, but instead only up to the last one it needs for the key
> > > comparisons.
> >
> > That’s true. Please see v3.
>
> Thanks. I did one further small change, namely to determine these last
> attnums just once per run rather than once per tuple. Pushed now.
I appreciate that REPACK can handle more cases now! However, I found a problem
(or at least a question) when rebasing the improvements for the next
release(s). (It's related to splitting the table scan into multiple block
ranges and use one snapshot per range, details are not too important here, )
Assertion failure in the new code made me think if other than B-tree indexes
should be allowed in the USING INDEX clause of REPACK.
AFAICS, only B-tree indexes (and some special ones that don't appear in the
core) provide ordering information - see get_relation_info():
/*
* Fetch the ordering information for the index, if any.
*/
if (info->relam == BTREE_AM_OID)
{
...
info->sortopfamily = info->opfamily;
...
}
else if (amroutine->amcanorder)
{
/*
* Otherwise, identify the corresponding btree opfamilies
* by trying to map this index's "<" operators into btree.
* Since "<" uniquely defines the behavior of a sort
* order, this is a sufficient test.
...
}
else
{
...
info->sortopfamily = NULL;
...
}
Therefore, index scan shouldn't be possible for GIST index - see
build_index_paths():
index_is_ordered = (index->sortopfamily != NULL);
So I'm not sure if clustering makes sense here. What makes me confused is that
GIST has IndexAmRoutine.amclusterable=true. As it has amcanorder=false at the
same time, I suspect it might be just a thinko. However, if we simply set
amclusterable to false, it can break upgrade to PG 19 for users who already
"clustered" some table by a GIST index (for mysterious reasons). (BTW, do we
need the amclusterable field at all?)
REPACK currently rejects explicit sort if non-B-tree index is specified (due
to lack of ordering information), but it still scans the index rather than
the heap - see copy_table_data() and heapam_relation_copy_for_cluster().
Does this seem worth fixing now? Or maybe at least worth some comments (unless
I'm completely wrong)?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Fix REPACK with WITHOUT OVERLAPS replica identity indexes
In-Reply-To: <70401.1778604528@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox