On Mon, 14 Jul 2025 17:25:22 -0400
Greg Sabino Mullane wrote:
[…]
> > Other than picking an arbitrary value (i.e. 5000), any thoughts about how
> > to build a case around a specific value ?
>
>
> Do you have actual examples of queries / situations that are harmed by the
> current settings? Let
On Mon, 2025-07-14 at 17:25 -0400, Greg Sabino Mullane wrote:
> Tom wrote:
> > > BTW, I would say largely the same things about JIT
>
> Yeah, that would change this from a few people conversing over tea
> into a large angry mob bearing pitchforks.
Oh yes, I'd much rather disable JIT by default th
(picking up the thread again too)
>> Five minutes?! That's not been my experience. Not claiming parallelism
is perfect yet,
>> but there are plenty of parallel performance savings under the five
minute mark.
> Absolutely, I've seen 1 second queries go to 200ms with parallelism of
2. The problem
On Mon, Jul 14, 2025, at 2:41 PM, Tom Lane wrote:
> "Scott Mead" writes:
> > I'd like to re-open the discussion for this commitfest item. I still have
> > not been able to find a value for parallel_setup_cost that makes good
> > decisions about parallelism on a user's behalf. I believe that
"Scott Mead" writes:
> I'd like to re-open the discussion for this commitfest item. I still have
> not been able to find a value for parallel_setup_cost that makes good
> decisions about parallelism on a user's behalf. I believe that setting the
> SIGHUP-able max_parallel_workers_per_gather t
On Wed, May 21, 2025, at 10:55 AM, Scott Mead wrote:
>
>
> On Wed, May 21, 2025, at 3:50 AM, Laurenz Albe wrote:
> > On Tue, 2025-05-20 at 16:58 -0400, Scott Mead wrote:
> > > On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> > > > On Tue, 2025-05-13 at 17:53 -0400, Scott Mead wrote:
> >
On Wed, May 21, 2025, at 3:50 AM, Laurenz Albe wrote:
> On Tue, 2025-05-20 at 16:58 -0400, Scott Mead wrote:
> > On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> > > 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, 2025-05-20 at 16:58 -0400, Scott Mead wrote:
> On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> > 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:
> > > >
On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> 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 au
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.
15 matches
Mail list logo
