Re: More thorough planning for OLAP queries (was: [PATCH] Equivalence Class Filters)

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

In response to

Browse pgsql-hackers by date

  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