Horton

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: John Naylor <john.naylor@2ndquadrant.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Joerg Sonnenberger <joerg@bec.de>, David Rowley <david.rowley@2ndquadrant.com>, John Naylor <jcnaylor@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-01-09T19:58:54Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2019-01-09 14:44:24 -0500, Tom Lane wrote:
>> /* fast lookup only possible if original oid still assigned */
>> -	if (id >= FirstGenbkiObjectId)
>> +	if (id > fmgr_last_builtin_oid)
>> 		return NULL;

> An extern reference here will make the code a bit less efficient, but
> it's probably not worth generating a header with a define for it
> instead...

Yeah, also that would be significantly more fragile, in that it'd
be hard to be sure where that OID had propagated to when rebuilding.
We haven't chosen to make fmgr_nbuiltins a #define either, and I think
it's best to treat this the same way.

			regards, tom lane

Commits

  1. Use perfect hashing, instead of binary search, for keyword lookup.

  2. Reduce the size of the fmgr_builtin_oid_index[] array.

  3. Replace the data structure used for keyword lookup.