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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 7 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedApr 25, '04 at 9:31p
activeApr 28, '04 at 9:14a
posts7
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase