On Wed, Aug 26, 2020 at 4:21 PM Andy Fan wrote:
>
>
> On Mon, Aug 17, 2020 at 10:12 PM Andy Fan
> wrote:
>
>>
>>
>> On Mon, Jun 22, 2020 at 9:39 AM Tom Lane wrote:
>>
>>> I wrote:
>>> > Nope. The entire reason why we have that kluge is that we don't know
>>> > until much later how many times w
On Mon, Aug 17, 2020 at 10:12 PM Andy Fan wrote:
>
>
> On Mon, Jun 22, 2020 at 9:39 AM Tom Lane wrote:
>
>> I wrote:
>> > Nope. The entire reason why we have that kluge is that we don't know
>> > until much later how many times we expect to execute the subplan.
>> > AlternativeSubPlan allows th
On Mon, Jun 22, 2020 at 9:39 AM Tom Lane wrote:
> I wrote:
> > Nope. The entire reason why we have that kluge is that we don't know
> > until much later how many times we expect to execute the subplan.
> > AlternativeSubPlan allows the decision which subplan form to use to be
> > postponed till
Hi Tom,
sorry for the delay,
I experimented with adding a number-of-evaluations parameter to
cost_qual_eval, and found that the majority of call sites do have
something realistic they can pass. The attached very-much-WIP
patch shows my results so far. There's a lot of loose ends:
I like the i
Hi Melanie,
Sorry for the delay.
I've just started looking at this patch today, but I was wondering if
you might include a test case which minimally reproduces the original
problem you had.
I could reproduce it with an easier generated data set, please see attached.
However, to be honest with
I wrote:
> Nope. The entire reason why we have that kluge is that we don't know
> until much later how many times we expect to execute the subplan.
> AlternativeSubPlan allows the decision which subplan form to use to be
> postponed till runtime; but when we're doing things like estimating the
> c
Tomas Vondra writes:
> I'm not particularly familiar with AlternativeSubPlans, but I see we're
> picking the one in nodeSubplan.c based on plan_rows. Can't we do the
> same thing in cost_qual_eval_walker?
Nope. The entire reason why we have that kluge is that we don't know
until much later how m
On Wed, Jun 17, 2020 at 06:21:58PM -0700, Melanie Plageman wrote:
On Fri, Jun 5, 2020 at 9:08 AM Alexey Bashtanov wrote:
In [1] we found a situation where it leads to a suboptimal plan,
as it bloats the overall cost into large figures,
a decision related to an outer part of the plan look negl
On Fri, Jun 5, 2020 at 9:08 AM Alexey Bashtanov wrote:
>
> In [1] we found a situation where it leads to a suboptimal plan,
> as it bloats the overall cost into large figures,
> a decision related to an outer part of the plan look negligible to the
> planner,
> and as a result it doesn't elaborat
On Fri, Jun 5, 2020 at 9:08 AM Alexey Bashtanov wrote:
>
> In [1] we found a situation where it leads to a suboptimal plan,
> as it bloats the overall cost into large figures,
> a decision related to an outer part of the plan look negligible to the
> planner,
> and as a result it doesn't elaborat
Hello,
Currently, in case of alternative subplans that do hashed vs per-row
lookups,
the per-row estimate is used when planning the rest of the query.
It's also coded in not quite an explicit way.
In [1] we found a situation where it leads to a suboptimal plan,
as it bloats the overall cost in
11 matches
Mail list logo
