Re: Brain dump: btree collapsing

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: Brain dump: btree collapsing
Дата
Msg-id 1045171956.1630.4.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Brain dump: btree collapsing  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Brain dump: btree collapsing  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: loading libraries on Postmaster startup
Следующее
От: mlw
Дата:
Сообщение: Re: location of the configuration files