Re: Brain dump: btree collapsing - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Brain dump: btree collapsing
Date
Msg-id 1045206446.1386.6.camel@fuji.krosing.net
Whole thread Raw
In response to Re: Brain dump: btree collapsing  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Brain dump: btree collapsing
List pgsql-hackers
Tom Lane kirjutas R, 14.02.2003 kell 01:13:
> Hannu Krosing <hannu@tm.ee> writes:
> > But if we would allow the scans to find the same keys twice without ill
> > effects (as was suggested earlier, for using btrees to index arrays),
>
> How is returning the same data twice not an "ill effect"?

>From earlier discussions I understood that there had been some work done
on using btrees for indexing arrays by storing each separate element in
a löeaf node. Surely that work must deal with not returning the same
tuple twice.

> > then we could possibly 1) copy the key to the right 2) wait for all
> > right-to-left scans that have fallen between old and new values to pass
> > and only then 3) delete the "old left" key.
>
> How will you wait for scans that you know nothing of to go past?
> Especially when they are going to be blocked by your own write lock
> on the left page?

could we just not lock (for more than just to ensure atomic writes) the
page but instead increment a "page version" on each write to detect
changes?

------------
Hannu




pgsql-hackers by date:

Previous
From: Oliver Elphick
Date:
Subject: Re: location of the configuration files
Next
From: "Andrew Dunstan"
Date:
Subject: Re: location of the configuration files