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 Thursday, July 17, 2025, David Rowley wrote:
>
>
> I suggest to Greg that he might want to come up with a method to make
> this configurable and a means to get something close to what we get
> today and default the setting to that. It would also be easier to
> follow any proposed algorithms wit
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
This is my first attempt for a patch to postgresql, please forgive me if
I have forgotten some step.
I recently got a new system, with many more CPU cores than previous
systems than I am used to, 128 cores
(which may not seem a large number to some). I was a bit unhappy that
even though I conf
11 matches
Mail list logo
