Re: BTree vacuum before page splitting - Mailing list pgsql-patches

Tom Lane wrote:
> I think this is quite likely to break things :-(.  What sort of
> conditions have you tested it under?  (If this were safe, we'd
> not have invented the LP_DELETE flag to begin with, but just have
> deleted known-dead items immediately.)

I apologize for my insufficient description(and bad english).
I explain the operation of this patch in detail again.

In _bt_insertonpg(), we insert the tupple by the following methods.

 (1) Finds the right place(page) to insert the tuple.
 (2) If free space is insufficient, we operate as follows.
+ (2.1) Confirm whether the lock to the found page is considerable
        super-exclusive lock in BufferSuperLockHeldByMe()[new]. We
        check bufHdr->refcount(=pin), and if pin == 1, we know this
        lock is super-exclusive lock.
        If our lock is not super-exclusive lock, goto (2.4).
+ (2.2) If our lock is super-exclusive lock, and the found page is
        leaf, we look for tupples marked as "LP_DELETE" from the found
        page, and remove found tuples in _bt_vacuum_page()[new].
+ (2.3) If free space is sufficient after removal, goto (4).
  (2.4) Step right to next non-dead page.
  (2.5) (2) is repeated until an enough free space is found or it
        reaches a right edge at last.
 (3) When an enough free space is not found by processing (2), splits
     the target page (making sure that the split is equitable as far as
     post-insert free space goes).
 (4) Inserts the tuple.

The numbers from 2.1) to 2.3) are new processing.

The pointer's shifting by removing "LP_DELETE" tuples as shown in the
above-mentioned becomes a problem, when we resume a stopped indexscan.
Therefore, I am having it confirm the state of the lock by (2.1), and
process only at super-exclucive lock, same as btbulkdelete().

However, because own indexscan might be lost because of this removal,
I also modify _bt_restscan() as follows.

 (1) Check for index tuple we stopped on.
 (2) If index tuple is moved, first of all, we search in this page
     right.
+(3) If not found, we try to look for from the head of this page
     because index tuple may moved left due to removal.
 (4) If still not found, we look for index tuple right.

The number (3) is new processing.

We do not delete the empty page. Therefore, there is no necessity for
tracing a left page.

I think that no problem occurs by this logic.
Please point it out if there is a wrong point. Thanks.

(I think that we might do not have to obtain super-exclucive lock by
processing (3) in _bt_restscan(), but it needs careful to do that.)


> BTW, a patch that makes major changes in the behavior of a function
> and doesn't update the code comments is unacceptable.  The comments
> are as important as the code, if not more so, because other people
> are going to have to read this after you.

I'm sorry. I will write the comment more, and I will contribute the
patch again.

--
Junji Teramoto / teramoto.junji (a) lab.ntt.co.jp