On Tue, Jul 22, 2025 at 8:49 PM David Rowley wrote:
> I don't think having a GUC which allows exactly two settings is
> anywhere near as flexible as you could make this.
I would phrase it as being a GUC with two settings currently,
I think it is easier to go from 2 possible algorithms to 3 than
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 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
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
On Thu, May 26, 2022 at 3:10 PM Tom Lane wrote:
Can you do anything useful with attaching selectivity estimates
to the functions it references, instead?
I may have been doing down a bad path before. The function I'm
working to improve has five argument, the last being "degrees", which
is the ma
On Thu, May 26, 2022 at 3:10 PM Tom Lane wrote:
> Greg Hennessy writes:
> > I'm trying to include a sensitivity operator in a function. My issue is
> > that when I have my function, I get a call to SupportRequestSimplify, but
> > not SupportRequestSensitivity. It is n
I'm trying to include a sensitivity operator in a function. My issue is
that when I have my function, I get a call to SupportRequestSimplify, but
not SupportRequestSensitivity. It is not obvious what I am doing that is
incorrect.
My c (stub) function is:
PG_FUNCTION_INFO_V1(pgq3c_join_selectivity
