Re: speedup tidbitmap patch: cache page - Mailing list pgsql-hackers

From David Rowley
Subject Re: speedup tidbitmap patch: cache page
Date
Msg-id CAApHDvr8f9UnfWZpVY0OEfd_Eoxa7Br_29j+fkZQ3-Qi=fU36w@mail.gmail.com
Whole thread Raw
In response to Re: speedup tidbitmap patch: cache page  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: speedup tidbitmap patch: cache page  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 24 December 2014 at 00:24, Teodor Sigaev <teodor@sigaev.ru> wrote:
I've also attached some benchmark results using your original table from
up-thread. It seems that the caching if the page was seen as lossy is not much
of a help in this test case. Did you find another one where you saw some better
gains?

All what I found is about 0.5%...  v3 contains your comments but it doesn't use
lossy_page cache.


Ok, I've performed some more benchmarks (attached) using your original table. I'm thinking the v2.3 version is not worth the extra complexity. It seems the extra caching in v2.3, going by my benchmarks, is more likely to add overhead than save from hash lookups. 

With the query used in my tests using v2.3 I didn't even see a speed up with 5 million records and 64KB of work_mem.

So I think v3 is the one to go with, and I can't see any problems with it, so I'm marking it as ready for committer.

Nice work

Kind Regards

David Rowley
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes
Next
From: Michael Paquier
Date:
Subject: Moving RestoreBlockImage from xlogreader.c to xlogutils.c