Re: HOT is applied - Mailing list pgsql-hackers

From Tom Lane
Subject Re: HOT is applied
Date
Msg-id 19881.1190343350@sss.pgh.pa.us
Whole thread Raw
In response to Re: HOT is applied  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: HOT is applied
List 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


pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: ecpg PREPARE is not thread safe
Next
From: "Pavan Deolasee"
Date:
Subject: Re: HOT is applied