Re: Brain dump: btree collapsing

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-13 21:32:36
Message-ID: 1045171956.1630.4.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane kirjutas N, 13.02.2003 kell 20:10:
> "Curtis Faith" <curtis(at)galtcapital(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message mlw 2003-02-13 21:44:05 Re: location of the configuration files
Previous Message mlw 2003-02-13 21:26:37 Re: location of the configuration files