On Mon, Aug 5, 2013 at 6:19 PM, Tom Lane wrote:
> Atri Sharma writes:
>>> 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.
>>> Th
Ashutosh Bapat writes:
> Can we change the query_planner() to return both the paths (presorted and
> unsorted) irrespective of the cost of presorted path, and let
> grouping_planner() (or any caller of query_planner()) handle which of them
> to pick up?
That's exactly the result this change would
Atri Sharma writes:
>> 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():
> On Mon, Aug 5, 2013 at 3:50 AM, Tom Lane 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.
> Can you please mention the subject of the thread? I tried to locate the t
> I agree with the idea,but am trying to understand why adding understanding of
> resjunk columns is a bad idea. Just for understanding purpose, could you
please
> elaborate a bit on it?
Although I may not have understood your question correctly, I think it is good
to see
http://www.postgresql.or
On Mon, Aug 5, 2013 at 3:50 AM, Tom Lane 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.
Can you please mention the subject of the thread? I tried to locate the
thread
> 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 introduce
> Robert Haas writes:
> > On Sun, Aug 4, 2013 at 6:20 PM, Tom Lane wrote:
> >> 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()).
>
> > I tend to th
Robert Haas writes:
> On Sun, Aug 4, 2013 at 6:20 PM, Tom Lane wrote:
>> 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()).
> I tend to think this is a
On Sun, Aug 4, 2013 at 6:20 PM, Tom Lane 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
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 bet
11 matches
Mail list logo
