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

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, 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-09T20:32:37Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-01-09 15:03:35 -0500, Tom Lane wrote:
>> (Speaking of which, I've been wondering for awhile if libpq ought not
>> obtain the OIDs of lo_create and friends by #including fmgroids.h
>> instead of doing a runtime query on every connection.  If we did that,
>> we'd be forever giving up the option to renumber them ... but do you
>> really want to bet that nobody else has done this already in some
>> other client code?)

> I'm not enthusiastic about that. I kinda hope we're going to evolve that
> interface further, which'd make it version dependent anyway (we don't
> require all of them right now...). And it's not that expensive to query
> their oids once.

Version dependency doesn't seem like much of an argument: we'd just teach
libpq to pay attention to the server version, which it knows anyway (and
uses for other purposes already).

But this is a bit off-topic for this thread, perhaps.

			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.