Re: gist vacuum gist access

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Костя Кузнецов <chapaev28(at)ya(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: gist vacuum gist access
Date: 2014-09-08 07:13:44
Message-ID: 540D5728.5090804@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/07/2014 05:11 PM, Костя Кузнецов wrote:
> hello.
> i recode vacuum for gist index.
> all tests is ok.
> also i test vacuum on table size 2 million rows. all is ok.
> on my machine old vaccum work about 9 second. this version work about 6-7 sec .
> review please.

If I'm reading this correctly, the patch changes gistbulkdelete to scan
the index in physical order, while the old code starts from the root and
scans the index from left to right, in logical order.

Scanning the index in physical order is wrong, if any index pages are
split while vacuum runs. A page split could move some tuples to a
lower-numbered page, so that the vacuum will not scan those tuples.

In the b-tree code, we solved that problem back in 2006, so it can be
done but requires a bit more code. In b-tree, we solved it with a
"vacuum cycle ID" number that's set on the page halves when a page is
split. That allows VACUUM to identify pages that have been split
concurrently sees them, and "jump back" to vacuum them too. See commit
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5749f6ef0cc1c67ef9c9ad2108b3d97b82555c80.
It should be possible to do something similar in GiST, and in fact you
might be able to reuse the NSN field that's already set on the page
halves on split, instead of adding a new "vacuum cycle ID".

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2014-09-08 07:18:25 Re: Optimization for updating foreign tables in Postgres FDW
Previous Message Pavel Stehule 2014-09-08 07:02:57 Re: proposal: ignore null fields in not relation type composite type based constructors