On 09/08/2014 03:26 PM, Alexander Korotkov wrote:
On Mon, Sep 8, 2014 at 12:51 PM, Heikki Linnakangas <hlinnakan...@vmware.com
wrote:
On 09/08/2014 11:19 AM, Alexander Korotkov wrote:
On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov <aekorot...@gmail.com
wrote:
On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas <
hlinnakan...@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.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
