Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes
От | Tom Lane |
---|---|
Тема | Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes |
Дата | |
Msg-id | 2130228.1668748896@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: Optimize join selectivity estimation by not reading MCV stats for unique join attributes
|
Список | pgsql-hackers |
Richard Guo <guofenglinux@gmail.com> writes: > 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. > 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. regards, tom lane
В списке pgsql-hackers по дате отправления: