David Rowley <david.rowley@2ndquadrant.com> writes:
> On 6 April 2017 at 10:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> 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.
Generally, if it's passed as zero, that's a good clue that the clause
*is* a join clause. In any case, this defense fails to address my
other question, which is what's going to happen to this API when you
want to use extended stats in join-clause estimates, which I'd expect
to surely happen before very long.
Also, I find it hard to believe that a bms_get_singleton_member call is
going to be material in comparison to all the work that will be invoked
indirectly via whatever selectivity estimation function gets called for
each clause. Even a single catcache fetch would swamp that.
So no, you have not convinced me that this isn't a broken design.
> FWIW, I found this function being called 72 times in a 5 way join
> search problem.
And you measured the overhead of doing it the other way to be ... ?
Premature optimization and all that.
regards, tom lane
