Re: pgbench client-side performance issue on large scripts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench client-side performance issue on large scripts
Date: 2025-02-26 00:17:53
Message-ID: 1675883.1740529073@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v2-0001-Get-rid-of-O-N-2-script-parsing-overhead-in-pgben.patch text/x-diff 12.3 KB
v2-0002-Avoid-unnecessary-computation-of-pgbench-s-script.patch text/x-diff 3.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-02-26 00:20:42 Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation
Previous Message Jeff Davis 2025-02-26 00:17:37 Re: Statistics Import and Export