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
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 |