Re: GiST nitpicks I want to discuss (and maybe eventually fix)
От | Kirill Reshke |
---|---|
Тема | Re: GiST nitpicks I want to discuss (and maybe eventually fix) |
Дата | |
Msg-id | CALdSSPiMpp=oa4J7+ZKuLDxAXEU0ca6S7D0W3FkHKFuz0uHUvA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GiST nitpicks I want to discuss (and maybe eventually fix) (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: GiST nitpicks I want to discuss (and maybe eventually fix)
|
Список | pgsql-hackers |
On Mon, 6 Oct 2025 at 23:53, Andrey Borodin <x4mmm@yandex-team.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 getrid 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
В списке pgsql-hackers по дате отправления: