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

Re: COPY Fillfactor patch

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Hannu Krosing <hannu(at)tm(dot)ee>, pgsql-patches(at)postgresql(dot)org,Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: COPY Fillfactor patch
Date: 2005-04-20 16:05:55
Message-ID: 1114013155.16721.2275.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-patches
On Wed, 2005-04-20 at 09:42 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Wed, 2005-04-20 at 09:03 -0400, Bruce Momjian wrote:
> >> My guess is that the FILLFACTOR will actually be a GUC variable rather
> >> than a clause to CREATE INDEX or REINDEX or CLUSTER.
> 
> > I hope not, but it would be easier to set like that and a lot easier to
> > code up that way.
> 
> I don't like that either.  It seems highly unlikely that every table in
> a database would need the same fillfactor.  It should be a per-table
> attribute, maybe with a DB-wide default, much like we handle per-column
> statistics targets.
> 
> My thought about this is that the case where extra free space really
> helps is UPDATE: if heap_update can put the new tuple version on the
> same page where the old one is, there's a noticeable savings.  So what
> you'd probably want is that heap_insert respects fillfactor (ie, won't
> eat the last fillfactor percent of a page) but heap_update doesn't,
> if it can thereby put the update on the same page.  As long as you
> vacuum before a particular page is entirely filled by updates of its
> own tuples, you have a steady-state situation.

Agreed. Thats the best approach.

Best Regards, Simon Riggs


In response to

pgsql-patches by date

Next:From: Oliver SiegmarDate: 2005-04-21 07:10:02
Subject: Re: BUG #1609: Bug in interval datatype for 64 Bit timestamps
Previous:From: Alvaro HerreraDate: 2005-04-20 13:58:59
Subject: Re: FW: Implementation of SQLSTATE and SQLERRM variables

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