Re: Handing off SLRU fsyncs to the checkpointer
От | Jakub Wartak |
---|---|
Тема | Re: Handing off SLRU fsyncs to the checkpointer |
Дата | |
Msg-id | VI1PR0701MB69606A503B9712970C2B6219F6550@VI1PR0701MB6960.eurprd07.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Handing off SLRU fsyncs to the checkpointer (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | 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 по дате отправления: