Re: pgbench client-side performance issue on large scripts
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Daniel Verite" <daniel@manitou-mail.org>
Cc: pgsql-hackers@postgresql.org
Date: 2025-02-26T00:17:53Z
Lists: pgsql-hackers
Attachments
- v2-0001-Get-rid-of-O-N-2-script-parsing-overhead-in-pgben.patch (text/x-diff) patch v2-0001
- v2-0002-Avoid-unnecessary-computation-of-pgbench-s-script.patch (text/x-diff) patch v2-0002
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 calculation to be done only after we see a backslash. I'd spent a little time worrying about how the calculation was really giving a wrong line number: typically, it'd return the line number of the previous semicolon, since we haven't lexed any further than that. That could be fixed with more code, but it's pretty pointless if we don't need the value in the first place. Also, I did a tiny bit of micro-optimization in the first patch to remove the hazard that it'd still be O(N^2) with very long input lines. regards, tom lane
Commits
-
Avoid unnecessary computation of pgbench's script line number.
- 6eb8a1a4f90c 18.0 landed
-
Get rid of O(N^2) script-parsing overhead in pgbench.
- c8c74ad7e1cb 18.0 landed