Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
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

pgsql-performance by date

Next:From: Vivek KheraDate: 2004-08-27 20:34:29
Subject: Re: Anyone familiar with Apple Xserve RAID
Previous:From: Dennis BjorklundDate: 2004-08-27 19:49:12
Subject: Re: Why those queries do not utilize indexes?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group