Re: Equivalent praxis to CLUSTERED INDEX?

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.

In response to

Browse pgsql-performance by date

  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?