On Tue, Sep 9, 2014 at 12:47 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 09/08/2014 03:26 PM, Alexander Korotkov wrote:
>>
>> On Mon, Sep 8, 2014 at 12:51 PM, Heikki Linnakangas
>> <hlinnakangas@vmware.com
>>>
>>> wrote:
>>
>>
>>> On 09/08/2014 11:19 AM, Alexander Korotkov wrote:
>>>
>>>> On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov
>>>> <aekorotkov@gmail.com
>>>>>
>>>>>
>>>> wrote:
>>>>
>>>> On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas <
>>>>>
>>>>> hlinnakangas@vmware.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.
This patch has been in a "Wait on Author" state for quite a long time
and Heikki has provided comments on it. Switching it to "Returned with
feedback".
--
Michael
