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

From Hannu Krosing
Subject Re: Brain dump: btree collapsing
Date
Msg-id 1045171956.1630.4.camel@localhost.localdomain
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 N, 13.02.2003 kell 20:10:
> "Curtis Faith" <curtis@galtcapital.com> writes:
> > I don't dispute their conclusions in that context and under the
> > circumstances they outline of random distribution of deletion and
> > insertion values for the index keys.  [But the random-distribution
> > assumption doesn't always hold.]
> 
> That's a fair point.  Nonetheless, we have little choice: we cannot
> move keys around during concurrent operations.  If we push keys to
> the right, we may cause an indexscan moving left to miss them, and
> vice versa.  So we can only eliminate empty pages.

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),
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. 

This could solve the concurrency issue as well.

> We could possibly allow VACUUM FULL to collapse partly-full pages,
> since in that case we know there are no concurrent scans.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: loading libraries on Postmaster startup
Next
From: mlw
Date:
Subject: Re: location of the configuration files