Tom Lane wrote:
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
