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: John Naylor <john.naylor@2ndquadrant.com>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, 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-08T20:04:36Z
Lists: pgsql-hackers

Attachments

John Naylor <john.naylor@2ndquadrant.com> writes:
> On Tue, Jan 8, 2019 at 12:06 PM Andrew Dunstan
> <andrew.dunstan@2ndquadrant.com> wrote:
>> If he doesn't I will.

> I'll take a crack at separating into a module.  I'll wait a bit in
> case there are any stylistic suggestions on the patch as it stands.

I had a go at that myself.  I'm sure there's plenty to criticize in
the result, but at least it passes make check-world ;-)

I resolved the worry I had last night about the range of table values
by putting in logic to check the range and choose a suitable table
element type.  There are a couple of existing calls where we manage
to fit the hashtable elements into int8 that way; of course, by
definition that doesn't save a whole lot of space since such tables
couldn't have many elements, but it seems cleaner anyway.

			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.