From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Naylor <jcnaylor(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: reducing the footprint of ScanKeyword (was Re: Large writable variables) |
Date: | 2018-12-17 22:39:28 |
Message-ID: | 25160.1545086368@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
John Naylor <jcnaylor(at)gmail(dot)com> writes:
> A few months ago I was looking into faster search algorithms for
> ScanKeywordLookup(), so this is interesting to me. While an optimal
> full replacement would be a lot of work, the above ideas are much less
> invasive and would still have some benefit. Unless anyone intends to
> work on this, I'd like to flesh out the offset-into-giant-string
> approach a bit further:
Have at it...
> Since PL/pgSQL uses the core scanner, we'd need to use offsets in its
> reserved_keywords[], too. Those don't change much, so we can probably
> get away with hard-coding the offsets and the giant string in that
> case. (If that's not acceptable, we could separate that out to
> pl_reserved_kwlist.h and reuse the above tooling to generate
> pl_reserved_kwlist_{offset,string}.h, but that's more complex.)
plpgsql isn't as stable as all that: people propose new syntax for it
all the time. I do not think a hand-maintained array would be pleasant
at all.
Also, wouldn't we also adopt this technology for its unreserved keywords,
too?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-12-17 22:46:29 | Re: Copypasta in the PostgreSQL source |
Previous Message | Simon Riggs | 2018-12-17 22:37:16 | Re: 'infinity'::Interval should be added |