Le 12/04/2023 à 20:06, Robert Haas a écrit :
There's only one existing test case that visibly changes plan with
these changes. The new plan is clearly saner-looking than before,
and testing with some data loaded into the table confirms that it
is faster. I'm not sure if it's worth devising m
Richard Guo writes:
> So +1 to 0001 patch.
> Also +1 to 0002 patch.
Pushed, thanks for looking at it!
regards, tom lane
On Fri, Jul 14, 2023 at 5:44 AM Tom Lane wrote:
> I tried both of those and concluded they'd be too messy for a patch
> that we might find ourselves having to back-patch. So 0001 attached
> fixes it by teaching SS_finalize_plan to treat optimized MIN()/MAX()
> aggregates as if they were already
I wrote:
> Eventually I noticed that all the failing cases were instances of
> optimizing MIN()/MAX() aggregates into indexscans, and then I figured
> out what the problem is: we substitute Params for the optimized-away
> Aggref nodes in setrefs.c, *after* SS_finalize_plan has been run.
> That mean
I wrote:
> Richard Guo writes:
>> On Mon, Apr 17, 2023 at 11:04 PM Tom Lane wrote:
>>> I wondered about that too, but how come neither of us saw non-cosmetic
>>> failures (ie, actual query output changes not just EXPLAIN changes)
>>> when we tried this?
>> Sorry I forgot to mention that I did se
On Tue, Apr 18, 2023 at 9:33 PM Tom Lane wrote:
> Richard Guo writes:
> > It seems that in this case the top_plan does not have any extParam, so
> > the Gather node that is added atop the top_plan does not have a chance
> > to get its initParam filled in set_param_references().
>
> Oh, so maybe
Richard Guo writes:
> On Mon, Apr 17, 2023 at 11:04 PM Tom Lane wrote:
>> I wondered about that too, but how come neither of us saw non-cosmetic
>> failures (ie, actual query output changes not just EXPLAIN changes)
>> when we tried this?
> Sorry I forgot to mention that I did see query output c
On Mon, Apr 17, 2023 at 11:04 PM Tom Lane wrote:
> Richard Guo writes:
> > So now it seems that the breakage of regression tests is more severe
> > than being cosmetic. I wonder if we need to update the comments to
> > indicate the potential wrong results issue if we move the initPlans to
> > t
Richard Guo writes:
> So now it seems that the breakage of regression tests is more severe
> than being cosmetic. I wonder if we need to update the comments to
> indicate the potential wrong results issue if we move the initPlans to
> the Gather node.
I wondered about that too, but how come neit
On Mon, Apr 17, 2023 at 10:57 AM Richard Guo wrote:
> The initPlan has been moved from the Result node to the Gather node. As
> a result, when doing tuple projection for the Result node, we'd get a
> ParamExecData entry with NULL execPlan. So the initPlan does not get
> chance to be executed.
On Thu, Apr 13, 2023 at 10:00 PM Tom Lane wrote:
> Richard Guo writes:
> > * For the diff in standard_planner, I was wondering why not move the
> > initPlans up to the Gather node, just as we did before. So I tried that
> > way but did not notice the breakage of regression tests as stated in th
Richard Guo writes:
> * For the diff in standard_planner, I was wondering why not move the
> initPlans up to the Gather node, just as we did before. So I tried that
> way but did not notice the breakage of regression tests as stated in the
> comments. Would you please confirm that?
Try it with
On Thu, Apr 13, 2023 at 12:43 AM Tom Lane wrote:
> Pursuant to the discussion at [1], here's a patch that removes our
> old restriction that a plan node having initPlans can't be marked
> parallel-safe (dating to commit ab77a5a45). That was really a special
> case of the fact that we couldn't tr
On Wed, Apr 12, 2023 at 12:44 PM Tom Lane wrote:
> Pursuant to the discussion at [1], here's a patch that removes our
> old restriction that a plan node having initPlans can't be marked
> parallel-safe (dating to commit ab77a5a45). That was really a special
> case of the fact that we couldn't tra
Pursuant to the discussion at [1], here's a patch that removes our
old restriction that a plan node having initPlans can't be marked
parallel-safe (dating to commit ab77a5a45). That was really a special
case of the fact that we couldn't transmit subplans to parallel
workers at all. We fixed that
15 matches
Mail list logo
