Re: pgbench client-side performance issue on large scripts

From: "Daniel Verite" <daniel(at)manitou-mail(dot)org>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench client-side performance issue on large scripts
Date: 2025-02-25 13:10:31
Message-ID: ff1a01b7-b78e-4fd8-a682-4fd768d6c335@manitou-mail.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 that ...

I guess my use case is unusual, otherwise the O(N^2) parse
time would have been noticed sooner, but it's genuine.

I want to see how much a long sequence of statement inside a
pipeline differs between pgbench and psql with
the proposed patch at [1] that implements pipelining in psql.
psql would not actually send statements until \endpipeline is
reached, whereas pgbench does.
In fact I'd be inclined to push much more statements in the pipeline
than 50k, but then the parse time issue really kicks in.

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() .

[1] https://commitfest.postgresql.org/patch/5407/

Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2025-02-25 13:14:39 Re: Redact user password on pg_stat_statements
Previous Message Andrew Dunstan 2025-02-25 12:45:10 Re: RFC: Additional Directory for Extensions