Re: B-tree parent pointer and checkpoints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Subject: Re: B-tree parent pointer and checkpoints
Date: 2010-11-11 18:34:46
Message-ID: 18661.1289500486@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Hmm, we don't currently keep track of that when we descend the tree to
> choose the target page, but perhaps an extra Consistent call to check
> that would be acceptable. We already call Penalty for every tuple on
> each internal node on the way, so compared to that one more call should
> not be too expensive. If we do that, I think it would simplify the
> algorithm quite a bit to just update all the parents on the way down,
> instead of traversing up from the bottom after inserting the tuple to
> the leaf.

Oh, that's a really good idea, I think. But what about page splits?
I guess in the case of a split, you'd be replacing the parent entry
anyway, so having previously updated it to something larger doesn't
really cause a problem other than wasting a few cycles --- which are
probably still less than you save by not having to traverse back up.

If we supported UNIQUE GIST indexes then you could criticize this plan
on the grounds that parent entries would get uselessly enlarged before
detecting a uniqueness failure; but we don't and I know of no plans to.
So on the whole I think it sounds good. Teodor, what do you think?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-11-11 18:45:55 Re: MULTISET and additional functions for ARRAY
Previous Message Nicolas Barbier 2010-11-11 18:24:00 Re: MULTISET and additional functions for ARRAY