Hi,
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.
Greetings,
Andres Freund