Re: [HACKERS] btbulkdelete

2004-04-28 Thread Manfred Koizar
On Wed, 28 Apr 2004 00:08:48 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: >> Is there a special reason for scanning the leaf pages in *logical* >> order, i.e. by following the opaque->btpo_next links? > >Yes. [..] interlocking between indexscans and deletions. Thanks for refreshing my memory. This

Re: [HACKERS] btbulkdelete

2004-04-27 Thread Tom Lane
Manfred Koizar <[EMAIL PROTECTED]> writes: > Is there a special reason for scanning the leaf pages in *logical* > order, i.e. by following the opaque->btpo_next links? Yes. Read the README file concerning interlocking between indexscans and deletions. regards, tom lane -

Re: [HACKERS] btbulkdelete

2004-04-27 Thread Simon Riggs
On Mon, 2004-04-26 at 17:24, Manfred Koizar wrote: > On Mon, 26 Apr 2004 14:29:58 +0100, Simon Riggs <[EMAIL PROTECTED]> > wrote: > >> Now that FSM > >> covers free btree index pages this access pattern might be highly > >> nonsequential. > > > >I had considered implementing a mode where the inde

Re: [HACKERS] btbulkdelete

2004-04-26 Thread Manfred Koizar
On Mon, 26 Apr 2004 14:29:58 +0100, Simon Riggs <[EMAIL PROTECTED]> wrote: >> 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 d

Re: [HACKERS] btbulkdelete

2004-04-26 Thread Alvaro Herrera
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 ac

Re: [HACKERS] btbulkdelete

2004-04-26 Thread Simon Riggs
On Sun, 2004-04-25 at 22:34, Manfred Koizar wrote: > On -performance we have been discussing a configuration where a bulk > delete run takes almost a day (and this is not due to crappy hardware or > apparent misconfiguration). Unless I misinterpreted the numbers, > btbulkdelete() processes 85 inde

[HACKERS] btbulkdelete

2004-04-25 Thread Manfred Koizar
On -performance we have been discussing a configuration where a bulk delete run takes almost a day (and this is not due to crappy hardware or apparent misconfiguration). Unless I misinterpreted the numbers, btbulkdelete() processes 85 index pages per second, while lazy vacuum is able to clean up 6