From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Pavan Deolasee" <pavan(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: HOT patch, missing things |
Date: | 2007-08-09 10:16:30 |
Message-ID: | 2e78013d0708090316n982614k4a5088017cc34fd8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/9/07, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
>
> Whether I got the exact details of frugging & depruning correct or not:
> if a tuple version is removed, then VACUUM doesn't need to remove it
> later, so any non-VACUUM removal of rows must defer a VACUUM.
>
>
ISTM that you are worried about the cases where a tuple is HOT updated
and hence can be pruned/defragged, but only if we revisit the page at
a later time.
What if we just track the amount of potentially dead space in the relation
(somebody had suggested that earlier in the thread) ? Every committed
UPDATE/DELETE and aborted UPDATE/INSERT would increment
the dead space. Whenever page fragmentation is repaired, either during
normal operation or during vacuum, the dead space is reduced by the
amount of reclaimed space. Autovacuum triggers whenever the percentage
of dead space increases beyond a threshold.
We can some fine tuning to track the space consumed by redirect-dead
line pointers.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-08-09 11:29:40 | Re: HOT patch, missing things |
Previous Message | Oleg Bartunov | 2007-08-09 10:03:13 | Re: default_text_search_config and expression indexes |