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

Andrew Dunstan <andrew.dunstan@2ndquadrant.com>

From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: John Naylor <jcnaylor@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Andrew Gierth <andrew@tao11.riddles.org.uk>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-12-27T20:20:41Z
Lists: pgsql-hackers
On 12/27/18 3:00 PM, John Naylor wrote:
> On 12/27/18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> diff --git a/src/tools/gen_keywords.pl b/src/tools/gen_keywords.pl
>> +	elsif ($arg =~ /^-o/)
>> +	{
>> +		$output_path = length($arg) > 2 ? substr($arg, 2) : shift @ARGV;
>> +	}
>>
>> My perl-fu is not great, but it looks like this will accept arguments
>> like "-ofilename", which is a style I don't like at all.  I'd rather
>> either insist on the filename being separate or write the switch like
>> "-o=filename".  Also, project style when taking both forms is usually
>> more like
>> 	-o filename
>> 	--offset=filename
> This style was cargo-culted from the catalog scripts. I can settle on
> just the first form if you like.
>


I would rather we used the standard perl module Getopt::Long, as
numerous programs we have already do.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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.