| From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: HOT patch - version 15 |
| Date: | 2007-09-06 18:05:57 |
| Message-ID: | 46E04185.7070708@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Simon Riggs wrote:
> Yes, the main point is that an UPDATE doesn't always allow you to prune.
You can always remove dead HOT tuples in heap_update. But you can never
defragment the page at that point.
> If it did, that would be the right place. Since it doesn't the best
> place to prune is surely the first time we see we *can* prune.
Not necessarily. Pruning is expensive, you need to scan all tuples on
the page and write WAL record. And defragment the page if you consider
that part of pruning. You don't want to do it too aggressively.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2007-09-06 18:20:40 | Re: create index concurrently blocks on transactions in other databases |
| Previous Message | Magnus Hagander | 2007-09-06 17:59:58 | Re: [HACKERS] pg_regress config |