Re: upper planner path-ification

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: robertmhaas(at)gmail(dot)com
Cc: andrew(at)tao11(dot)riddles(dot)org(dot)uk, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: upper planner path-ification
Date: 2015-05-20 02:06:02
Message-ID: 20150520.110602.139352652.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 19 May 2015 09:04:00 -0400, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in <CA+TgmobAV3_DS1sXA+PFWkjvX1K-VNiAnMMJrzPfD43g=-4OYA(at)mail(dot)gmail(dot)com>
> On Tue, May 19, 2015 at 7:19 AM, Andrew Gierth
> <andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
> >>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> > Tom> Hm. That's a hangover from when query_planner also gave back a
> > Tom> Plan (singular) rather than a set of Paths. I don't see any
> > Tom> fundamental reason why we couldn't generalize it to be a list of
> > Tom> potentially useful output orderings rather than just one. But I'm
> > Tom> a bit concerned about the ensuing growth in planning time; is it
> > Tom> really all that useful?
> >
> > The planning time growth is a possible concern, yes. The potential gain
> > is eliminating one sort step, in the case when the input has a usable
> > sorted path but grouping_planner happens not to ask for it (when there's
> > more than just a single rollup, the code currently asks for one of the
> > sort orders pretty much arbitrarily since it has no real way to know
> > otherwise). Whether that would justify it... I don't know. Maybe that's
> > one to save for later to see if there's any feedback from actual use.
>
> I kind of doubt that the growth in planning time would be anything too
> unreasonable. We already consider multiple orderings for ordinary
> base relations, so it's not very obvious why consideration multiple
> orderings for subqueries would be any worse. If we can arrange to
> throw away useless orderings early, as we do in other cases, then any
> extra paths we consider have a reasonable chance of being useful.

Though I don't think that the simple path-ification of what is
currently done make it grow in any degree, it could rapidly grow
if we unconditionally construct extra upper-paths using the
previously-abandoned extra paths or make them involved in join
considerations. But the growth in planning time could be kept
reasonable if we pay attention so that, as we have done so, the
additional optimization schemes to have simple and precise
bailing-out logic even if they require some complicated
calculation or yields more extra paths.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-05-20 02:17:55 Re: RFC: Non-user-resettable SET SESSION AUTHORISATION
Previous Message Jim Nasby 2015-05-20 01:05:46 Re: Change pg_cancel_*() to ignore current backend