Re: tune postgres for UPDATE

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
Cc: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Sebastian Böhm <seb(at)exse(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: tune postgres for UPDATE
Date: 2008-12-09 18:09:40
Message-ID: 2e78013d0812091009n2a965900wa14132ab7771225e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Dec 9, 2008 at 9:13 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>wrote:

>
>
> I'm pretty sure you'd have to vacuum still in between runs or the
> extra fill factor space would only get used the first time. I.e.:
>
> create table fill factor 50%
> load data into table
> update whole table -- 50% free space gets used.
> (should vacuum here but didn't)
> update whole table -- boom, new tuples are added onto the end of the table.
>
>
Not really with 8.3. Assuming there are no long running transactions
covering both the updates, HOT will free up the space used by the old (now
DEAD) tuples and the second update will reuse that, at least for for the
most common cases.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Madison Kelly 2008-12-09 20:59:02 Re: SELECT DISTINCT ... ORDER BY problem
Previous Message Tony Linden 2008-12-09 18:09:17 q query about a bug.