Horton

Re: GiST VACUUM

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Костя Кузнецов <chapaev28@ya.ru>
Date: 2018-07-13T14:25:47Z
Lists: pgsql-hackers 
Looking at the second patch, to scan the GiST index in physical order, 
that seems totally unsafe, if there are any concurrent page splits. In 
the logical scan, pushStackIfSplited() deals with that, by comparing the 
page's NSN with the parent's LSN. But I don't see anything like that in 
the physical scan code.

I think we can do something similar in the physical scan: remember the 
current LSN position at the beginning of the vacuum, and compare with 
that. The B-tree code uses the "cycle ID" for similar purposes.

Do we still need the separate gistvacuumcleanup() pass, if we scan the 
index in physical order in the bulkdelete pass already?

- Heikki

Commits

  1. Use full 64-bit XID for checking if a deleted GiST page is old enough.

  2. Refactor checks for deleted GiST pages.

  3. Delete empty pages during GiST VACUUM.

  4. Scan GiST indexes in physical order during VACUUM.

  5. Prevent GIN deleted pages from being reclaimed too early