Re: query_planner() API change

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: query_planner() API change
Date: 2013-08-05 00:28:21
Message-ID: CA+TgmoYv97o4qNLOuCpZyq0FpBumLGUUpvJj-gesZa33j4GzaA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Aug 4, 2013 at 6:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I've been looking at what it would take to do proper cost estimation
> for the recently-discussed patch to suppress calculation of unnecessary
> ORDER BY expressions. It turns out that knowledge of that would have
> to propagate into query_planner(), because the place where we do the cost
> comparison between unsorted and presorted paths is in there (planmain.c
> lines 390ff in HEAD). As it stands, query_planner() will actually refuse
> to return the presorted path to grouping_planner() at all if it thinks
> it's a loser cost-wise, meaning grouping_planner() would have no
> opportunity to override the decision. So there's no way to fix this
> without some API change for query_planner().
>
> While we could complicate query_planner()'s API even more to add some
> understanding of unnecessary resjunk items, I think this is probably
> the straw that breaks the camel's back for the current approach here.
> There is already a comment like this in query_planner():
>
> * This introduces some undesirable coupling between this code and
> * grouping_planner, but the alternatives seem even uglier; we couldn't
> * pass back completed paths without making these decisions here.
>
> I think it's time to bite the bullet and *not* pass back completed paths.
> What's looking more attractive now is to just pass back the top-level
> RelOptInfo ("final_rel" in query_planner()). We could remove all three
> output parameters of query_planner(), and essentially just move lines
> 265-420 (pretty much everything after the make_one_rel() call) into
> planner.c. Since that code is almost all about grouping-related choices,
> this seems like it'll be a net improvement modularity-wise, even though
> it'll make grouping_planner() even bigger. We could probably ameliorate
> the latter problem by putting the calculation of num_groups and adjustment
> of tuple_fraction into a subroutine.
>
> Objections, better ideas?

I tend to think this is a pretty good plan.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-08-05 00:31:25 Re: Review: UNNEST (and other functions) WITH ORDINALITY
Previous Message Tom Lane 2013-08-04 22:20:05 query_planner() API change