Re: track_planning causing performance regression
| От | Andres Freund |
|---|---|
| Тема | Re: track_planning causing performance regression |
| Дата | |
| Msg-id | 20200629230019.o75zwqtfiolxbkw2@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: track_planning causing performance regression (Julien Rouhaud <rjuju123@gmail.com>) |
| Список | pgsql-hackers |
Hi, On 2020-06-29 09:05:18 +0200, Julien Rouhaud wrote: > I can't reproduce this on my laptop, but I can certainly believe that > running the same 3 queries using more connections than available cores > will lead to extra overhead. > I disagree with the conclusion though. It seems to me that if you > really have this workload that consists in these few queries and want > to get better performance, you'll anyway use a connection pooler > and/or use prepared statements, which will make this overhead > disappear entirely, and will also yield an even bigger performance > improvement. It's an extremely common to have have times where there's more active queries than CPUs. And a pooler won't avoid that fully, at least not without drastically reducing overall throughput. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: