Re: GiST VACUUM - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: GiST VACUUM
Date
Msg-id 0E0DF52D-8E01-4A37-A9C5-3B9A7E6E53DD@yandex-team.ru
Whole thread Raw
In response to Re: GiST VACUUM  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: GiST VACUUM  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers

> 16 июля 2018 г., в 18:58, Robert Haas <robertmhaas@gmail.com> написал(а):
>
> On Fri, Jul 13, 2018 at 10:10 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> I'm still a bit scared about using pd_prune_xid to store the XID that
>> prevents recycling the page too early. Can we use some field in
>> GISTPageOpaqueData for that, similar to how the B-tree stores it in
>> BTPageOpaqueData?
>
> What's your reason for being scared?  It seems to me that the
> alternatives being proposed (altering the size of the special space,
> or sometimes repurposing a field for some other purpose) have their
> own associated scariness.

Thanks, that's exactly what I'm thinking about where to store this xid.

Here's v9 of the patch, it uses pd_prune_xid, but it is abstracted to GistPageGetDeleteXid() \ GistPageSetDeleteXid()
sothat we can change the way we store it easily. 

Best regards, Andrey Borodin.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions