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: John Naylor <john.naylor@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>,
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-09T22:21:01Z
Lists: pgsql-hackers
John Naylor <john.naylor@2ndquadrant.com> writes: > On Wed, Jan 9, 2019 at 2:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> [patch to shrink oid index] > It would help maintaining its newfound sveltness if we warned if a > higher oid was assigned, as in the attached. I used 6200 as a soft > limit, but that could be anything similiar. I think the reason we have this issue is that people tend to use high OIDs during development of a patch, so that their elbows won't be joggled by unrelated changes. Then sometimes they forget to renumber them down before committing. A warning like this would lead to lots of noise during the development stage, which nobody would thank us for. If we could find a way to notice this only when we were about to commit, it'd be good .. but I don't have an idea about a nice way to do that. (No, I don't want a commit hook on gitmaster; that's warning too late, which is not better.) regards, tom lane
Commits
-
Use perfect hashing, instead of binary search, for keyword lookup.
- c64d0cd5ce24 12.0 landed
-
Reduce the size of the fmgr_builtin_oid_index[] array.
- 8ff5f824dca7 12.0 landed
-
Replace the data structure used for keyword lookup.
- afb0d0712f1a 12.0 landed