Re: pgbench client-side performance issue on large scripts - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgbench client-side performance issue on large scripts
Date
Msg-id 1474697.1740429059@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgbench client-side performance issue on large scripts  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Yeah, we do rely on yylineno in bootscanner.l and ecpg, but not
> elsewhere; not sure if there's a performance reason for that.

Ah: the flex manual specifically calls out "%option yylineno"
as something that has a moderate performance cost.  So that's
why we don't use it except in non-performance-critical scanners.

Now, it could be argued that pgbench's script scanner doesn't
rise to that level of performance-criticalness, especially not
if we're paying the cost of counting newlines some other way.
I'm not excited about doing a lot of performance analysis here
to decide that.  I think we could steal plpgsql's idea to
keep the code structure basically the same while avoiding the
O(N^2) repeat scans, and that should be enough.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: James Hunter
Date:
Subject: Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators