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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:02:16
Message-ID: 20170927190216.kcqqhkbwexyj4v2h@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-09-27 14:58:36 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Honestly before going there I'd rather just have
> > an oid indexed array, computed at compile time.
>
> 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.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-09-27 19:06:15 Re: Binary search in fmgr_isbuiltin() is a bottleneck.
Previous Message Tom Lane 2017-09-27 18:58:36 Re: Binary search in fmgr_isbuiltin() is a bottleneck.