From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Curtis Faith <curtis(at)galtcapital(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Brain dump: btree collapsing |
Date: | 2003-02-14 07:07:27 |
Message-ID: | 1045206446.1386.6.camel@fuji.krosing.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane kirjutas R, 14.02.2003 kell 01:13:
> Hannu Krosing <hannu(at)tm(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2003-02-14 07:35:03 | Re: location of the configuration files |
Previous Message | Oliver Elphick | 2003-02-14 06:37:30 | Re: location of the configuration files |