| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: remove flatfiles.c |
| Date: | 2009-09-03 00:31:11 |
| Message-ID: | 407d949e0909021731q49fd757dl6ef655d9c30a1330@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 2, 2009 at 11:55 PM, Ron Mayer<rm_pg(at)cheapcomplexdevices(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2009-09-03 00:37:16 | Re: remove flatfiles.c |
| Previous Message | Erik Rijkers | 2009-09-03 00:21:18 | Re: initdb: The password file was not generated. |