Re: HOT is applied

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HOT is applied
Date: 2007-09-21 02:55:50
Message-ID: 19881.1190343350@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> ... so basically it's all about the locking. Maybe the problem is that with
> HOT we lock the buffer too often? heap_page_prune_opt is designed to
> not take the buffer lock unless there's a good probability of needing
> to prune, but maybe that's not working as intended.

Indeed it seems it's not; gprof shows

0.00 0.00 111/1389276 index_getnext <cycle 7> [89]
0.05 49.52 1389165/1389276 heapgetpage [6]
[8] 50.9 0.05 49.52 1389276 heap_page_prune_opt [8]
7.17 42.31 1366696/1366696 heap_page_prune [9]
0.01 0.03 1366696/1366696 ConditionalLockBufferForCleanup [106]
0.01 0.00 2755558/2780795 PageGetHeapFreeSpace [177]

so this example is getting past the heuristic tests in
heap_page_prune_opt almost every time. Why is that? Too tired to poke
at it more tonight.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2007-09-21 02:59:36 Re: HOT is applied
Previous Message ITAGAKI Takahiro 2007-09-21 02:05:47 ecpg PREPARE is not thread safe