> What this means is that if we start with "next" pointing at a page
> without enough space (quite likely considering that we now index all
> pages not only those with free space), then it is highly possible that
> the search will end on a page *before* where next was. The most trivial
> case is that we have an even-numbered page with a lot of free space and
> its odd-numbered successor has none --- in this case, far from spreading
> out the backends, all comers will be handed back that same page! (Until
> someone reports that it's full.) In general it seems that this behavior
> will tend to concentrate the returned pages in a small area rather than
> allowing them to range over the whole FSM page as was intended.
Good point.
> So the bottom line is that the "next" addition doesn't actually work and
> needs to be rethought. It might be possible to salvage it by paying
> attention to "next" during the descent phase and preferentially trying
> to descend to the right of "next"; but I'm not quite sure how to make
> that work efficiently, and even less sure how to wrap around cleanly
> when the starting value of "next" is near the last slot on the page.
Yeah, I think it can be salvaged like that. see the patch I just posted
on a separate thread.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment