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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joerg Sonnenberger <joerg(at)bec(dot)de>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, John Naylor <jcnaylor(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Date: 2019-01-06 22:08:59
Message-ID: 28027.1546812539@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joerg Sonnenberger <joerg(at)bec(dot)de> writes:
> On Sun, Jan 06, 2019 at 02:29:05PM -0500, Tom Lane wrote:
>> * We should extend the ScanKeywordList representation to include a
>> field holding the longest keyword length in the table, which
>> gen_keywordlist.pl would have no trouble providing. Then we could
>> skip downcasing and/or hashing for any word longer than that, replacing
>> the current NAMEDATALEN test, and thereby putting a tight bound on
>> the cost of downcasing and/or hashing.

> Correct, possibly even have an array for each class of keywords.

I added that change to v8 and noted a further small improvement in my
test case. That probably says something about the prevalence of long
identifiers in information_schema.sql ;-), but anyway we can figure
it's not a net loss.

I've pushed that version (v8 + max_kw_len); if the buildfarm doesn't
fall over, we can move on with looking at hashing.

I took a quick look through the NetBSD nbperf sources at

http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/nbperf/

and I concur with your judgment that we could manage translating
that into Perl, especially if we only implement the parts we need.
I'm curious what further changes you've made locally, and what
parameters you were using.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2019-01-06 22:40:16 Re: BUG #15446: Crash on ALTER TABLE
Previous Message Tom Lane 2019-01-06 20:24:55 Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)