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 17:00:32 |
Message-ID: | 20170927170032.lcvtnpt3qokknjys@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-09-27 11:50:56 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > I suppose an even better approach would be to build a perfect hash
> > table at compile time so that nothing needs to be built at run-time at
> > all, but I'm not sure it's worth the trouble.
>
> Yeah, I was wondering about that too. It would likely mean adding a
> compile time dependency on gperf or similar tool, but we could take
> our standard approach of shipping the output in tarballs, so that only
> developers would really need to install that tool.
I'd been wondering about that too, but I'm not sure I buy that it's
worth the effort. The only real argument I see is that there's probably
multiple cases where it'd be potentially beneficial, not just here.
> Rebuilding a constant table during every backend start seems like a
> pretty brute-force answer.
We could relatively easily move it to be once-per-postmaster start for
!EXEC_BACKEND builds. Constantly doing expensive binary searches is also
pretty brute force ;)
I've been wondering about not actually eagerly filling that hashtable,
but using it for pretty much all of fmgr.c - but that seems like a good
chunk more work...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Banck | 2017-09-27 17:15:59 | Re: Create replication slot in pg_basebackup if requested and not yet present |
Previous Message | Alexander Korotkov | 2017-09-27 16:51:23 | Re: Pluggable storage |