| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Greg Hennessy <greg(dot)hennessy(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: simple patch for discussion |
| Date: | 2025-07-18 04:23:57 |
| Message-ID: | CAKFQuwYzs63G5_i2kVDd1dP8i6WCdK2rs6L9zWzizw-MGQ+zHw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thursday, July 17, 2025, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:
> On Thursday, July 17, 2025, David Rowley <dgrowleyml(at)gmail(dot)com> 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 hint for important queries to be assigned saying
> “make this query go fast even if it doesn’t play nice with others”.
>
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 having to choose
a best algorithm. IOW, what would it take to make the proposed patch an
extension that a DBA could choose to install and override the current log3
algorithm?
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2025-07-18 04:43:54 | Re: Improve pg_sync_replication_slots() to wait for primary to advance |
| Previous Message | David G. Johnston | 2025-07-18 04:08:35 | Re: simple patch for discussion |