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

From: John Naylor <jcnaylor(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Date: 2019-01-04 20:46:32
Message-ID: CAJVSVGXqPJTDC2n-RosqXc+s=+ai+rZfP8LtEMtnbOJOGTbpYw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/27/18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> If you really are hot about saving that other 440 bytes, the way to
> do it would be to drop the struct entirely and use two parallel
> arrays, an int16[] for value and a char[] (or better uint8[]) for
> category. Those would be filled by reading kwlist.h twice with
> different definitions for PG_KEYWORD. Not sure it's worth the
> trouble though --- in particular, not clear that it's a win from
> the standpoint of number of cache lines touched.

Understood. That said, after re-implementing all keyword lookups, I
wondered if there'd be a notational benefit to dropping the struct,
especially since as yet no caller uses both token and category. It
makes pl_scanner.c and its reserved keyword list a bit nicer, and gets
rid of the need to force frontend to have 'zero' token numbers, but
I'm not sure it's a clear win. I've attached a patch (applies on top
of v6), gzipped to avoid confusing the cfbot.

-John Naylor

Attachment Content-Type Size
keyword-nostruct.patch.gz application/x-gzip 3.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Molotkov 2019-01-04 21:01:15 Re: BUG #15446: Crash on ALTER TABLE
Previous Message Andres Freund 2019-01-04 20:39:26 Re: pgsql: Remove WITH OIDS support, change oid catalog column visibility.