Re: btbulkdelete

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: btbulkdelete
Дата
Msg-id 20040426141822.GA4924@dcc.uchile.cl
обсуждение исходный текст
Ответ на Re: btbulkdelete  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Apr 26, 2004 at 02:29:58PM +0100, Simon Riggs wrote:
> On Sun, 2004-04-25 at 22:34, Manfred Koizar wrote:

> > Is there a special reason for scanning the leaf pages in *logical*
> > order, i.e. by following the opaque->btpo_next links?  Now that FSM
> > covers free btree index pages this access pattern might be highly
> > nonsequential.
>
> I had considered implementing a mode where the index doesn't keep trying
> to reuse space that was freed by earlier deletes. For many situations
> where you are processing bulk inserts and bulk deletes, reusing space
> via the FSM ends up weaving the logical sequence into a very unsorted
> physical sequence.
> 
> i.e. my thinking was about a way to keep logical looking more like
> physical, in certain situations.

See this:

@inproceedings{DBLP:conf/sigmod/ZouS96, author    = {Chendong Zou and Betty Salzberg}, editor    = {H. V. Jagadish and
InderpalSingh Mumick}, title     = {On-line Reorganization of Sparsely-populated B+trees}, booktitle = {Proceedings of
the1996 ACM SIGMOD International Conference on       Management of Data, Montreal, Quebec, Canada, June 4-6, 1996},
publisher= {ACM Press}, year      = {1996}, pages     = {115-124}, bibsource = {DBLP, \url{http://dblp.uni-trier.de}}
 
}

Maybe it can be useful.

When I tried to implement it, there was no free-pages code, so first I
had to do that (Tom Lane beat me to it though).  Then I had to choose a
different project.  Maybe now it can be done.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
One man's impedance mismatch is another man's layer of abstraction.
(Lincoln Yeoh)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: Usability, MySQL, Postgresql.org, gborg, contrib, etc.
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: FW: getting a crash during initdb