Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes

Thanks everyone for the great feedback and suggestions.

>
>> Yes, it is.  Using zero flag would short-cut get_attstatsslot() to just
>> return whether the slot type exists without loading it.  Do you think we
>> need to emphasize this use case in the comments for 'flags'?
> Perhaps, it's not really obvious now.

Comment added.


> I wonder whether we need to also check statistic_proc_security_check()
>> when determining if MCVs exists in both sides.
> Yeah, I thought about hoisting the statistic_proc_security_check
> tests up into get_mcv_stats.  I don't think it's a great idea
> though.  Again, it'd complicate untangling this if we ever
> generalize the use of MCVs in this function.  Also, I don't
> think we should be micro-optimizing the case where the security
> check doesn't pass --- if it doesn't, you're going to be hurting
> from bad plans a lot more than you are from some wasted cycles
> here.

Sounds reasonable.

Attached is v2 of the patch.
This is basically Tom's version plus a comment for the flags of 
get_attstatslot() as suggested by Richard.

I couldn't come up with any reasonable way of writing an automated test 
for that.
Any ideas?

--
David Geier
(ServiceNow)