Re: Binary search in fmgr_isbuiltin() is a bottleneck.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>,
Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>,
PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2017-09-28T18:59:45Z
Lists: pgsql-hackers
Attachments
- testruntime.c (text/x-c)
I wrote: > [ we should use an index array ] Just to prove the point, I threw together the attached trivial test case, which time-trials the existing fmgr_isbuiltin implementation against both the proposed hash implementation and a simple index array. On my machine, with a repeat count of 10000, I get NOTICE: bsearch runtime 4234.087 ms NOTICE: hash runtime 2542.636 ms NOTICE: index runtime 165.184 ms (These numbers are repeatable within 1% or so.) It could be argued that trialling OIDs sequentially gives a bit of an unfair advantage to the bsearch and index methods over the hash method, because the former are going to suffer fewer cache misses that way. But I don't see a randomized lookup order changing the conclusion much. regards, tom lane
Commits
-
Replace binary search in fmgr_isbuiltin with a lookup array.
- 212e6f34d55c 11.0 landed
-
Add inline murmurhash32(uint32) function.
- 791961f59b79 11.0 cited