Re: track_planning causing performance regression

From: Andres Freund <andres(at)anarazel(dot)de>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: "Tharakan, Robins" <tharar(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: track_planning causing performance regression
Date: 2020-06-29 23:00:19
Message-ID: 20200629230019.o75zwqtfiolxbkw2@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-06-29 23:10:15 Re: track_planning causing performance regression
Previous Message Peter Geoghegan 2020-06-29 22:29:06 Re: track_planning causing performance regression