From: | Mischa Sandberg <ischamay(dot)andbergsay(at)activestateway(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Equivalent praxis to CLUSTERED INDEX? |
Date: | 2004-08-27 19:50:12 |
Message-ID: | UfMXc.66117$X12.27750@edtnps84 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2004-08-27 20:34:29 | Re: Anyone familiar with Apple Xserve RAID |
Previous Message | Dennis Bjorklund | 2004-08-27 19:49:12 | Re: Why those queries do not utilize indexes? |