"Daniel Verite" writes:
> Tom Lane wrote:
>> I got nerd-sniped by this question and spent some time looking into
>> it.
> Thank you for the patch! LGTM.
Thanks for reviewing! Pushed after a tiny bit more polishing.
regards, tom lane
Tom Lane wrote:
> > I got nerd-sniped by this question and spent some time looking into
> > it.
Thank you for the patch! LGTM.
Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
I wrote:
> I got nerd-sniped by this question and spent some time looking into
> it.
On second look, I'd failed to absorb your point about how the main
loop of ParseScript doesn't need the line number at all; only if
it's a backslash command are we going to use that. So we can
move the calculatio
"Daniel Verite" writes:
> For the moment I'll stay with my quick fix, then l'll try
> to come up with something to replace expr_scanner_get_lineno() .
I got nerd-sniped by this question and spent some time looking into
it. ParseScript has got worse problems than just being slow: it's
actively bu
Tom Lane wrote:
> > I see "pgbench -f 50k-select.sql" taking about 5.8 secs of CPU time,
> > out of a total time of 6.7 secs. When run with perf, this profile shows up:
>
> You ran only a single execution of a 50K-line script? This test
> case feels a little bit artificial. Having said
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-p
"Daniel Verite" writes:
> On large scripts, pgbench happens to consume a lot of CPU time.
> For instance, with a script consisting of 5 "SELECT 1;"
> I see "pgbench -f 50k-select.sql" taking about 5.8 secs of CPU time,
> out of a total time of 6.7 secs. When run with perf, this profile shows u
