Re: Open issues for HOT patch

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Open issues for HOT patch
Date: 2007-09-18 15:58:55
Message-ID: 2e78013d0709180858ofa8e16er954602755acd06b9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/18/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>
> > Another option would be to prune whenever the free space goes
> > below table fillfactor
>
> If default fillfactor weren't 100% then this might be good ;-). But
> we could use max(1-fillfactor, BLCKSZ/8) or some such.
>
> > Yet another option would be to set a hint on the page whenever we
> > fail to do HOT update
>
> This would be a good idea independent of anything else, I think.
>
>

Or may be a combination of the above two would work well. If the user
has not specified any fillfactor (and so table is using default 100), the
first update is most likely a COLD update and we set the hint bit. The
retired tuple is then pruned before the next update comes and we shall
do HOT update. OTOH if the use has specified a fillfactor less than
to avoid any COLD update, the first update will be HOT. At that point,
the used space would go above fillfactor and hence we shall prune
before the next update comes making room for next HOT update.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-09-18 16:10:28 Re: Open issues for HOT patch
Previous Message Greg Smith 2007-09-18 15:51:12 Re: Just-in-time Background Writer Patch+Test Results