Re: HOT patch, missing things

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

In response to

Responses

Browse pgsql-hackers by date

  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