Re: Handing off SLRU fsyncs to the checkpointer - Mailing list pgsql-hackers

From Jakub Wartak
Subject Re: Handing off SLRU fsyncs to the checkpointer
Date
Msg-id VI1PR0701MB69606A503B9712970C2B6219F6550@VI1PR0701MB6960.eurprd07.prod.outlook.com
Whole thread Raw
In response to Re: Handing off SLRU fsyncs to the checkpointer  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Hi Alvaro, Thomas, hackers

>>     14.69%  postgres  postgres            [.] hash_search_with_hash_value
>>             ---hash_search_with_hash_value
>>                |--9.80%--BufTableLookup
[..]
>>                 --4.90%--smgropen
>>                           |--2.86%--ReadBufferWithoutRelcache
> Looking at an earlier report of this problem I was thinking whether it'd
> make sense to replace SMgrRelationHash with a simplehash table; I have a
> half-written patch for that, but I haven't completed that work.
> However, in the older profile things were looking different, as
> hash_search_with_hash_value was taking 35.25%, and smgropen was 33.74%
> of it.  BufTableLookup was also there but only 1.51%.  So I'm not so
> sure now that that'll pay off as clearly as I had hoped.

Yes, quite frankly my expectation was to see hash_search_with_hash_value()<-smgropen() outcome as 1st one, but in
simplifiedredo-bench script it's not the case. The original scenario was much more complex with plenty of differences
(inno particular order: TB-sized DB VS ~500GB RAM -> thousands of forks, multiple tables, huge btrees, multiple INSERTs
wihplenty of data in VALUES() thrown as one commit, real primary->hot-standby replication [not closed DB in recovery],
sortednot random UUIDs) - I'm going to try nail down these differences and maybe I manage to produce more realistic
"pgbenchreproducer" (this may take some time though). 

-Jakub Wartak.


pgsql-hackers by date:

Previous
From: Sachin Khanna
Date:
Subject: RE: Help needed configuring postgreSQL with xml support
Next
From: Thomas Munro
Date:
Subject: Re: Handing off SLRU fsyncs to the checkpointer