From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <bruce(at)momjian(dot)us>, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: HOT is applied |
Date: | 2007-09-21 15:02:49 |
Message-ID: | 46F3DD19.4060502@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> Bruce Momjian wrote:
>>> This might be a simplistic question but if the page is +90% full and
>>> there is a long-lived transaction, isn't Postgres going to try pruning
>>> on each page read access?
>
>> Yes :(
>
> It shouldn't, though --- the hint bit should get cleared on the first
> try.
Think so? That would mean that you only get a single chance to prune
after an update. Not sure how big a problem that is, but I do feel that
would make HOT a lot less effective in some usage patterns.
The idea of having a "prunable xmin" in the page header sounds more and
more attractive to me...
> I think I probably broke something in the last round of revisions
> to heap_page_prune_opt, but haven't looked yet ...
Pavan's patch was like that as well; you don't clear the flag (or
rather, you set it again while pruning) until there's nothing left to
prune on the page.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-21 15:04:21 | Re: HOT is applied |
Previous Message | Pavan Deolasee | 2007-09-21 14:49:13 | Re: HOT is applied |