Re: query_planner() API change - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: query_planner() API change
Date
Msg-id CAOeZVieabfN3nV9tckELkQQiLkzCuYGE7ax3BLR9dMz9sZe1pg@mail.gmail.com
Whole thread Raw
In response to query_planner() API change  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: query_planner() API change  ("Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>)
Re: query_planner() API change  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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 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?

Regards,

Atri




-- 
Regards,

Atri
l'apprenant



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Next
From: Ashutosh Bapat
Date:
Subject: Re: query_planner() API change