| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Michael <rmichael(at)edgeofthenet(dot)org> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Slow ext'd query via client native implementation vs. libpq & simple psql |
| Date: | 2020-03-11 22:54:16 |
| Message-ID: | 6262.1583967256@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Richard Michael <rmichael(at)edgeofthenet(dot)org> writes:
> On PG 12.2, I am analyzing a performance problem when using a client
> (Elixir/postgrex) querying via the extended query protocol. I am comparing
> with
> psql and a C program. Logs for all three follow this short explanation.
Hmm, your auto-explain log entries show all three queries having
server-side execution times of a couple dozen msec. It seems like
the excess time must be involved in transmitting the data to the
client. So I guess I'd be looking at whether the client is really
slow at absorbing data for some reason.
IIRC, auto-explain's 'actual time' for the top-level query node does not
count the time to format data or transmit it to the client. Still, we
have an upper bound of ~80 msec for that to happen with the libpq client,
and there's no obvious reason why it'd be different for the other client.
[ thinks for a bit... ] You might double check that those two clients
are using the same client_encoding setting. 400ms doing encoding
conversion seems excessive, but there aren't that many other possibilities
for the I/O time to be different.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2020-03-12 20:43:36 | Re: Slow ext'd query via client native implementation vs. libpq & simple psql |
| Previous Message | Justin Pryzby | 2020-03-11 21:59:21 | Re: Slow ext'd query via client native implementation vs. libpq & simple psql |