Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, I measured the performance of this patch considering > markpos/restorepos. The loss seems to be up to about 10% > unfortunately.
Thanks for the test case! I took another look at this optimization, and found that it didn't really depend on the pin (as I had first thought), so I put it back (keeping the rest of the patch unchanged). I saw a 1.4% increase in run time with the patch (compared to master) for the mark-only test, and a 1.6% increase in run time for the mark/restore test. I'll look into what might be causing that. I have seen bigger differences just due to changing where executable code crossed cache boundaries, but this is big enough to worry about; it needs to be checked. New patch attached. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
bt-nopin-v2.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
