Re: Unsplitting btree index leaf pages - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: Unsplitting btree index leaf pages
Date
Msg-id tu5rq1tni904qkuoo606o1bu16mdcubiep@4ax.com
Whole thread Raw
In response to Re: Unsplitting btree index leaf pages  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unsplitting btree index leaf pages
List pgsql-hackers
On Thu, 22 Dec 2005 10:40:24 -0500, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>If you move items
>from one page to the other in the opposite direction from the way the
>scan is going, then it will miss those items.

AFAIU the (PG implementaion of the) L&Y method is designed to make
scans immune against problems caused by items moving right within the
same page and against page splits, i.e. items moving to a *new* right
sibling.  So making scans work with items moving to an *existing*
right sibling doesn't seem out of reach.

The code following this comment in _bt_restscan
/** The item we're looking for moved right at least one page, so* move right.    We are careful here to pin and
read-lockthe next* non-dead page before releasing the current one.    This ensures* that a concurrent btbulkdelete scan
cannotpass our position* --- if it did, it might be able to reach and delete our target* item before we can find it
again.*/
looks like it'd work for the case of page merging as well, as long as
we are careful to move items always from left to right.

BTW, if after having locked both pages we find that we have
super-exclusive locks, i.e. nobody else has pins on these pages, we
can reorganize much more agressively.  It might even be safe to move
items to the left page.  The parent page might need some special
handling, though.

ServusManfred


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Merry Christmas!
Next
From: Kevin Brown
Date:
Subject: Re: Unsplitting btree index leaf pages