From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Benedikt Grundmann <bgrundmann(at)janestreet(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, david(at)fetter(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, jgh(at)wizmail(dot)org, itparanoia(at)gmail(dot)com, GavinFlower(at)archidevsys(dot)co(dot)nz, david(dot)g(dot)johnston(at)gmail(dot)com |
Subject: | Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters) |
Date: | 2015-12-30 21:03:36 |
Message-ID: | CAKJS1f9iih2p8AAFJJoPztupyRuaunHc+OwyY9On+ZH1-G3Czw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30 December 2015 at 21:12, Benedikt Grundmann <bgrundmann(at)janestreet(dot)com>
wrote:
> On Wed, Dec 30, 2015 at 7:16 AM, David Rowley <
> david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>
>>
>> A number of ideas were suggested on the other thread about how we might
>> go about solving this problem. In [3] Simon talked about perhaps enabling
>> extra optimisations when the planner sees that the plan will cost more than
>> some given threshold. That's perhaps an option, but may not work well for
>> optimisations which must take place very early in planning, for example [4].
>>
>
> A small tweak on 3 to deal with 4. If the returned plan cost is quite
> high (say you estimate minutes+) you could just restart planning from
> scratch with all costly planning enabled, because even in the worst case
> (that is the additional options don't find a better plan), the total
> planning cost won't matter much in the grand scheme of things.
>
I do personally quite like this idea. Quite likely the extra logic could be
added to the planner() function so that it calls standard_planner() again
in the event that the cost exceeds some specified threshold. I think the
planner might need a little bit of work before replanning on the same parse
is ok, as there's places where the planner makes changes to this object
which cause things not to work well during the replan. So I think if we
went down this route, then the first steps should be to find alternative
ways to do things so that the parse is never edited, and set new standards
that the parse cannot be changed within the planner anymore.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2015-12-30 21:30:27 | Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters) |
Previous Message | Oleksii Kliukin | 2015-12-30 20:29:59 | Re: rows estimate in explain analyze for the BRIN index |