From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Curtis Faith" <curtis(at)galtcapital(dot)com> |
Cc: | "'Hannu Krosing'" <hannu(at)tm(dot)ee>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Brain dump: btree collapsing |
Date: | 2003-02-14 16:19:56 |
Message-ID: | 7728.1045239596@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Curtis Faith" <curtis(at)galtcapital(dot)com> writes:
> Another way this could be handled is by not merging onto one of the
> existing pages but to a brand new page, a kind of special case shadow
> index page.
Hmmm ... that might be made to work, but it would complicate inserts.
By the time an insert navigates to the page it should insert on, it
might find the page is dead, and then it would have no easy way to get
to the replacement page (unless you want to dedicate another link field
in every index page for that one use). I suppose it could recover by
starting the search over again.
Another problem is that the two dead pages are now outside of the btree
structure and so their left and right links won't get updated in the
face of subsequent splits and merges of the nearby pages. I spent quite
a bit of time sweating over the recovery navigation details in my
original proposal; I can assure you it's not easy to get right. You can
chain right from a dead page with some reliability, but left is another
matter. There's no good way to know, when following a left link,
whether you've arrived at the proper place or need to chain right to
make up for a subsequent split. The recovery procedure I proposed works
for removing single pages, but it won't work with substituted pages.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-14 16:30:56 | Re: Brain dump: btree collapsing |
Previous Message | scott.marlowe | 2003-02-14 16:14:52 | Re: location of the configuration files |