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

Re: Equivalent praxis to CLUSTERED INDEX?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Adi Alurkar <adi(at)sf(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Equivalent praxis to CLUSTERED INDEX?
Date: 2004-08-27 19:42:50
Message-ID: 200408271942.i7RJgoR03090@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
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.

Oracle also does that chain thing so moving updates to different pages
might have more of an impact than it does on PostgreSQL.  We have chains
too but just for locking.  Not sure on Oracle.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-performance by date

Next:From: Dennis BjorklundDate: 2004-08-27 19:49:12
Subject: Re: Why those queries do not utilize indexes?
Previous:From: Greg StarkDate: 2004-08-27 19:34:57
Subject: Re: Equivalent praxis to CLUSTERED INDEX?

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