From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
---|---|
To: | Alexey Bashtanov <bashtanov(at)imap(dot)cc> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve planner cost estimations for alternative subplans |
Date: | 2020-06-17 01:15:50 |
Message-ID: | CAAKRu_ZAKdRa5CydfvSRwC_xwwboXEiqitXK4TMppHOcx7uu5A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 5, 2020 at 9:08 AM Alexey Bashtanov <bashtanov(at)imap(dot)cc> 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 elaborate on choosing the optimal one.
>
>
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.
The only plan diff I see is in updatable_views.sql, and it doesn't
illustrate the problem as well as a more straightforward SELECT query
with EXISTS sublink might.
After putting in some logging, I see that there are only a
few non-catalog queries which exercise this code path.
This query from groupingsets.sql is an example of one such query:
select ten, sum(distinct four) from onek a
group by grouping sets((ten,four),(ten))
having exists (select 1 from onek b where sum(distinct a.four) = b.four);
But, the chosen plan for this query stays the same.
It would be helpful to see a query where a different plan is chosen
because of this change that is not from updatable_views.sql.
--
Melanie Plageman
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-06-17 01:17:07 | Re: Review for GetWALAvailability() |
Previous Message | Kyotaro Horiguchi | 2020-06-17 01:01:21 | Re: Review for GetWALAvailability() |