Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes - Mailing list pgsql-hackers

From David Geier
Subject Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes
Date
Msg-id 712310f5-a5c7-b833-4f71-b562c5f2de9b@gmail.com
Whole thread Raw
In response to Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes
List pgsql-hackers
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)

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Reducing power consumption on idle servers
Next
From: Bharath Rupireddy
Date:
Subject: Re: Reducing power consumption on idle servers