On 2025-May-13, Scott Mead wrote:
> If you have a connection pool from your application and you issue 60
> queries per minute, each that can go from 1 second to 200 ms, That
> means that you are making 120 connections per minute back to the DB.
>
> As we know, connection establishment is brutal..
On Tue, 2025-05-13 at 17:53 -0400, Scott Mead wrote:
> On Tue, May 13, 2025, at 5:07 PM, Greg Sabino Mullane wrote:
> > On Tue, May 13, 2025 at 4:37 PM Scott Mead wrote:
> > > I'll open by proposing that we prevent the planner from automatically
> > > selecting parallel plans by default
> >
> > T
On Tue, May 13, 2025, at 5:07 PM, Greg Sabino Mullane wrote:
> On Tue, May 13, 2025 at 4:37 PM Scott Mead wrote:
>> I'll open by proposing that we prevent the planner from automatically
>> selecting parallel plans by default
>
> That seems a pretty heavy hammer, when we have things like
> pa
On Tue, May 13, 2025 at 4:37 PM Scott Mead wrote:
> I'll open by proposing that we prevent the planner from automatically
> selecting parallel plans by default
That seems a pretty heavy hammer, when we have things like
parallel_setup_cost that should be tweaked first.
The recommendation that I
On Tue, May 13, 2025 at 4:36 PM Scott Mead wrote:
> I'm looking forward to the upcoming monitoring in e7a9496 (Add two
> attributes to pg_stat_database for parallel workers activity), it will be
> easier to empirically prove that parallel query is being used. I don't
> think the patch goes far e
Hello Hackers,
Over the last 24 months, I've noticed a pattern amongst users with unexpected
plan flips landing on parallel plans.
77cd477 (9.6 beta) defaulted parallel query on (max_parallel_degree = 2), it's
been nine years and I'd like to open the discussion to see what our thoughts
are.
