Re: Slow ext'd query via client native implementation vs. libpq & simple psql
От | Tom Lane |
---|---|
Тема | Re: Slow ext'd query via client native implementation vs. libpq & simple psql |
Дата | |
Msg-id | 6262.1583967256@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Slow ext'd query via client native implementation vs. libpq & simple psql (Richard Michael <rmichael@edgeofthenet.org>) |
Список | pgsql-performance |
Richard Michael <rmichael@edgeofthenet.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
В списке pgsql-performance по дате отправления: