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/
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 |