Re: GiST VACUUM

x4mmm@yandex-team.ru

From: Andrey Borodin <x4mmm@yandex-team.ru>

To: Robert Haas <robertmhaas@gmail.com>

Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Thomas Munro <thomas.munro@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Костя Кузнецов <chapaev28@ya.ru>

Date: 2018-07-16T17:24:32Z

Lists: pgsql-hackers

Attachments

0002-Physical-GiST-scan-during-VACUUM-v9.patch (application/octet-stream) patch v9-0002
0001-Delete-pages-during-GiST-VACUUM-v9.patch (application/octet-stream) patch v9-0001


> 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() so that we can change the way we store it easily.

Best regards, Andrey Borodin.

Commits

Use full 64-bit XID for checking if a deleted GiST page is old enough.
- fb5344c969af 12.0 landed
- 6655a7299d83 13.0 landed
Refactor checks for deleted GiST pages.
- e2e992c93145 12.0 landed
- 9eb5607e6993 13.0 landed
Delete empty pages during GiST VACUUM.
- 7df159a620b7 12.0 landed
Scan GiST indexes in physical order during VACUUM.
- fe280694d0d4 12.0 landed
Prevent GIN deleted pages from being reclaimed too early
- 52ac6cd2d0cd 12.0 cited