Re: GiST nitpicks I want to discuss (and maybe eventually fix)

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GiST nitpicks I want to discuss (and maybe eventually fix)
Date: 2025-10-06 19:02:21
Message-ID: CALdSSPiMpp=oa4J7+ZKuLDxAXEU0ca6S7D0W3FkHKFuz0uHUvA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 6 Oct 2025 at 23:53, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:

Thank you for review

> Makes sense. I hope one day we will add a catalog field to track index creation version. This would pave the way to get rid of invalid GiST tuples and return this flag too. We can use it for something better.

In the GIN index we have an index creation version, and it is placed
on the metapage. So does btree, if i'm not mistaken . So, the index
version is stored in data, not in catalog. I doubt we will support two
technologies for one purpose. Since GiST index has no metapage, I
doubt we will be successful here.

>
> Yes, this is Hot-standby-only record. In offline conversation you mentioned that "RelFileLocator locator;" is not needed, only "Oid dbOid;". Maybe let's save a little more bytes?

It is about ResolveRecoveryConflictWithSnapshot. This function
RelFileLocator arg and only uses database oid. Changing this is too
out-of-scope.

--
Best regards,
Kirill Reshke

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-10-06 19:13:59 Re: plan shape work
Previous Message Andrey Borodin 2025-10-06 18:53:01 Re: GiST nitpicks I want to discuss (and maybe eventually fix)