Re: btbulkdelete

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 index pages per second, while lazy vacuum is
> able to clean up 620 heap pages per second.
>
> 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.

Best Regards, Simon Riggs