On Fri, Jul 18, 2025 at 12:23 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Framing this differently, how about a patch that lets extension authors
> choose to implement alternative formulas or even provide GUC-driven
> constants into the planner at the existing spot instead of havin
On Thursday, July 17, 2025, David G. Johnston
wrote:
> On Thursday, July 17, 2025, David Rowley wrote:
>
>>
>> I find it hard to imagine that there'd be many people
>>
> around that would benefit from a global
>> "always_use_this_number_of_parallel_workers" GUC.
>>
>
> Just to clarify, the globa
On Thursday, July 17, 2025, David Rowley wrote:
>
> I find it hard to imagine that there'd be many people
>
around that would benefit from a global
> "always_use_this_number_of_parallel_workers" GUC.
>
Just to clarify, the global value would be -1 usually. It would be another
crappy planner hin
On Fri, 18 Jul 2025 at 13:04, David G. Johnston
wrote:
> Have the planner produce two numbers.
>
> 1: This plan needs a minimum of N workers to make the parallelism worthwhile.
> Assume that is what we produce today.
> 2: A number representing how much this plan would benefit from the
> availa
Greg Hennessy writes:
Hi,
>> On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote:
>>> workers, but there isn't an easy way to get more
>>> workers.
> On 7/16/25 11:01 PM, David Rowley wrote:
>>> Is "alter table ... set (parallel_workers=N);" not easy enough?
>
> It may be easy enough for one tabl
On Fri, 18 Jul 2025 at 05:03, Andres Freund wrote:
> Right now we basically assume that the benefit of parallelism reduces
> substantially with every additional parallel worker, but for things like
> seqscans that's really not true. I've seen reasonably-close-to-linear
> scalability for parallel
Hi,
On 2025-07-17 15:01:55 +1200, David Rowley wrote:
> On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote:
> > workers, but there isn't an easy way to get more
> > workers.
>
> Is "alter table ... set (parallel_workers=N);" not easy enough?
I don't think that's a great approach, as that basical
On 7/16/25 11:01 PM, David Rowley wrote:
> Is "alter table ... set (parallel_workers=N);" not easy enough?
No opinions on the merit of the patch, but it's not as easy as better
default behavior, right? That is, the important questions are whether
the proposed behavior is better, and whether the c
On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote:
workers, but there isn't an easy way to get more
workers.
On 7/16/25 11:01 PM, David Rowley wrote:
Is "alter table ... set (parallel_workers=N);" not easy enough?
It may be easy enough for one table, but that won't work for joins as
far as
On Thu, 17 Jul 2025 at 12:44, Greg Hennessy wrote:
> workers, but there isn't an easy way to get more
> workers.
Is "alter table ... set (parallel_workers=N);" not easy enough?
David
10 matches
Mail list logo
