On 6 April 2017 at 10:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> Collect and use multi-column dependency stats
>
> The buildfarm is unhappy about the fact that this changed the API
> for clauselist_selectivity(). I am not convinced that that change
> was a good idea, so before telling FDW authors that they need to
> change their code, I'd like to hear a defense of the API change.
> Why not just use the existing varRelid parameter for that? Why
> is there an assumption that only one rel's extended stats will
> ever be of interest? This function does get used for join clauses.
Because varReliId is often passed in as 0, and that meant we'd have to
write some code to check of the clause was made up of RestrictInfos
from a single relation or not, and look for extended stats on that
singleton rel. Given the number of times this function gets called
during planning, especially so with queries involving many joins, I
think it's best to not have to extract the correct relids each time. I
coded it that way to reduce the overhead during planning, which is
something that often comes up with planner patches.
FWIW, I found this function being called 72 times in a 5 way join
search problem.
Perhaps there is a nicer way to do this, I just couldn't think of it.
-- David Rowley http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services