This discussion is starting to sound like the split in HEAP memory
management evolution, into garbage-collecting (e.g. Java) and
non-garbage-collecting (e.g. C++).
Reclamation by GC's these days has become seriously sophisticated.
CLUSTER resembles the first generation of GC's, which were
single-big-pass hold-everything-else threads.
Perhaps the latest in incremental GC algorithms would be worth scouting,
for the next step in PG page management.
Greg Stark wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>but is there any significant performance benefit to doing that which would
>>offset the compaction advantage?
> Just as a side comment. Setting PCTFREE 0 PCTUSED 100 on tables that have no
> updates on them has an astonishingly big effect on speed. So the penalty for
> leaving some space free really is substantial.
> I think the other poster is right. Oracle really needs pctfree because of the
> way it handles updates. Postgres doesn't really need as much because it
> doesn't try to squeeze the new tuple in the space the old one took up. If it
> doesn't fit on the page the worst that happens is it has to store it on some
> other page, whereas oracle has to do its strange row chaining thing.
In response to
pgsql-performance by date
|Next:||From: Vivek Khera||Date: 2004-08-27 20:34:29|
|Subject: Re: Anyone familiar with Apple Xserve RAID|
|Previous:||From: Dennis Bjorklund||Date: 2004-08-27 19:49:12|
|Subject: Re: Why those queries do not utilize indexes?|