From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Костя Кузнецов <chapaev28(at)ya(dot)ru> |
Subject: | Re: GiST VACUUM |
Date: | 2018-07-16 17:24:32 |
Message-ID: | 0E0DF52D-8E01-4A37-A9C5-3B9A7E6E53DD@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 16 июля 2018 г., в 18:58, Robert Haas <robertmhaas(at)gmail(dot)com> написал(а):
>
> On Fri, Jul 13, 2018 at 10:10 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)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() so that we can change the way we store it easily.
Best regards, Andrey Borodin.
Attachment | Content-Type | Size |
---|---|---|
0002-Physical-GiST-scan-during-VACUUM-v9.patch | application/octet-stream | 14.0 KB |
0001-Delete-pages-during-GiST-VACUUM-v9.patch | application/octet-stream | 18.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2018-07-16 17:28:09 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Tom Lane | 2018-07-16 17:21:17 | Re: [HACKERS] logical decoding of two-phase transactions |