Re: Remove useless associativity/precedence from parsers

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Akim Demaille <akim(at)lrde(dot)epita(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Remove useless associativity/precedence from parsers
Date: 2019-05-23 22:16:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2019-05-22 17:25:31 -0400, Tom Lane wrote:
> The easiest method is to fire up some client code that repeatedly
> does whatever you want to test, and then look at perf or oprofile
> or local equivalent to see where the time is going in the backend
> process.
> For the particular case of stressing the parser, probably the
> best thing to look at is test cases that do a lot of low-overhead
> DDL, such as creating views. You could do worse than just repeatedly
> sourcing our standard view files, like
> src/backend/catalog/system_views.sql
> src/backend/catalog/information_schema.sql
> (In either case, I'd suggest adapting the file to create all
> its objects in some transient schema that you can just drop.
> Repointing information_schema.sql to some other schema is
> trivial, just change a couple of commands at the top; and
> you could tweak system_views.sql similarly. Also consider
> wrapping the whole thing in BEGIN; ... ROLLBACK; instead of
> spending time on an explicit DROP.)
> Somebody else might know of a better test case but I'd try
> that first.

> There would still be a fair amount of I/O and catalog lookup
> overhead in a test run that way, but it would be an honest
> approximation of useful real-world cases. If you're willing to
> put some blinders on and just micro-optimize the flex/bison
> code, you could set up a custom function that just calls that
> stuff. I actually did that not too long ago; C code attached
> for amusement's sake.

FWIW, this is why I'd suggested the hack of EXPLAIN (PARSE_ANALYZE OFF,
OPTIMIZE OFF) a few years back. Right now it's hard to measure the
parser in isolation.


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-23 22:23:45 Re: ClosePipeStream failure ignored in pg_import_system_collations
Previous Message Tom Lane 2019-05-23 22:10:24 Re: SQL-spec incompatibilities in similar_escape() and related stuff