From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Open issues for HOT patch |
Date: | 2007-09-18 22:08:11 |
Message-ID: | 20070918220811.GA95343@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 18, 2007 at 11:32:52AM -0400, Tom Lane wrote:
> > Another option would be to prune whenever the free space goes
> > below table fillfactor and hope that users would set fillfactor so that
> > atleast one updated tuple can fit in the block. I know its not best to
> > rely on the users though. But it can be good hint.
>
> If default fillfactor weren't 100% then this might be good ;-). But
Erik Jones and I were just talking about FILLFACTOR...
Is the plan to keep it at 100% with HOT? ISTM that's not such a great
idea, since it forces at least the first update (if not many more) to be
COLD.
I realize that ideally we'd probably want FILLFACTOR to take things like
average tuple size and average number of updates per page into account,
but for a first pass 90% would likely be a good compromise...
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-18 22:18:34 | Re: [COMMITTERS] pgsql: Close previously open holes for invalidly encoded data to enter |
Previous Message | Andreas Joseph Krogh | 2007-09-18 18:17:20 | Re: 8.3 version of ts_headline |