Re: remove flatfiles.c - Mailing list pgsql-hackers

From Greg Stark
Subject Re: remove flatfiles.c
Date
Msg-id 407d949e0909021731q49fd757dl6ef655d9c30a1330@mail.gmail.com
Whole thread Raw
In response to Re: remove flatfiles.c  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
List pgsql-hackers
On Wed, Sep 2, 2009 at 11:55 PM, Ron Mayer<rm_pg@cheapcomplexdevices.com> wrote:
> Yet when I try it now, I'm having trouble making it work.
> Would you expect the ctid to be going down in the psql session
> shown below?  I wonder why it isn't.

Even before HOT we preferentially tried to put updated tuples on the
same page they were on before. On pre-8.3 if you did these updates
*without* the vacuum they would eventually be forced to find a new
page and hopefully would find one earlier in the table.

On 8.4 HOT will (hopefully) prevent even that from working. Unless you
have a long-running transaction in the background it will clean up the
old tuples in the chain on the page each time the page fills up.
You've deleted half the tuples on the page so the updates will always
fit in that space.

Eventually you'll hit the maximum number of tuples allowed on the page
dead or alive. But the vacuums are defeating that too.  A special
purpose command could work around all of this.

--
greg
http://mit.edu/~gsstark/resume.pdf


pgsql-hackers by date:

Previous
From: "Erik Rijkers"
Date:
Subject: Re: initdb: The password file was not generated.
Next
From: Greg Stark
Date:
Subject: Re: remove flatfiles.c