From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Костя Кузнецов <chapaev28(at)ya(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: gist vacuum gist access |
Date: | 2014-09-08 15:47:00 |
Message-ID: | 540DCF74.6000303@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/08/2014 03:26 PM, Alexander Korotkov wrote:
> On Mon, Sep 8, 2014 at 12:51 PM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com
>> wrote:
>
>> On 09/08/2014 11:19 AM, Alexander Korotkov wrote:
>>
>>> On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov <aekorotkov(at)gmail(dot)com
>>>>
>>> wrote:
>>>
>>> On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas <
>>>> hlinnakangas(at)vmware(dot)com> wrote:
>>>>
>>>> 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".
>>>>>
>>>> ...
>>>
>>> Another note. Assuming we have NSN which can play the role of "vacuum
>>> cycle
>>> ID", can we implement sequential (with possible "jump back") index scan
>>> for
>>> GiST?
>>
>> Yeah, I think it would work. It's pretty straightforward, the page split
>> code already sets the NSN, just when we need it. Vacuum needs to memorize
>> the current NSN when it begins, and whenever it sees a page with a higher
>> NSN (or the FOLLOW_RIGHT flag is set), follow the right-link if it points
>> to lower-numbered page.
>
> I mean "full index scan" feature for SELECT queries might be implemented as
> well as sequential VACUUM.
Oh, sorry, I missed that. If you implement a full-index scan like that,
you might visit some tuples twice, so you'd have to somehow deal with
the duplicates. For a bitmap index scan it would be fine.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2014-09-08 16:02:20 | BRIN indexes (was Re: Minmax indexes) |
Previous Message | Robert Haas | 2014-09-08 15:44:16 | Re: PQputCopyEnd doesn't adhere to its API contract |