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:44:24Z
Lists: pgsql-hackers

Attachments

I wrote:
> Also, I fail to understand why fmgr_builtin_oid_index has 10000 entries
> anyway.  We could easily have fmgrtab.c expose the last actually assigned
> builtin function OID (presently 6121) and make the index array only
> that big, which just about eliminates the space advantage completely.

Concretely, like the attached.

We could make the index table still smaller if we wanted to reassign
a couple dozen high-numbered functions down to lower OIDs, but I dunno
if it's worth the trouble.  It certainly isn't from a performance
standpoint, because those unused entry ranges will never be touched
in normal usage; but it'd make the server executable a couple KB smaller.

			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.