Re: Binary search in fmgr_isbuiltin() is a bottleneck.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Binary search in fmgr_isbuiltin() is a bottleneck.
Date: 2017-09-27 19:06:15
Message-ID: 12699.1506539175@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-09-27 14:58:36 -0400, Tom Lane wrote:
>> Yeah, I'd been kind of wondering about that approach too. We could have,
>> say, a table of int16s indexed by OIDs from 0 to 9999, containing zero or
>> an index into the table of FmgrBuiltin structs. So 20000 bytes of
>> constant data, and O(negligible) lookup time other than possible cache
>> misses on this table. But a dynahash-ish hash table built for 2800+
>> entries would probably be about that size ...

> Well dynahash is *way* too slow for this. But that's pretty much what
> the simplehash approach is already doing, anyway. Right now I think the
> correct approach would be to just add an fmgr_startup() function, called
> by postmaster / backend startup if EXEC_BACKEND.

Yeah, constructing an index table of that sort on top of the existing
FmgrBuiltin array could be done cheaply enough at startup. It irks me
slightly that it's not part of the read-only text segment, but I can't
say that there's any really measurable impact.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-09-27 19:11:16 Re: Binary search in fmgr_isbuiltin() is a bottleneck.
Previous Message Andres Freund 2017-09-27 19:02:16 Re: Binary search in fmgr_isbuiltin() is a bottleneck.