Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > On 2019-Feb-02, Tom Lane wrote: >> Another idea that I looked into is to not create RestrictInfos for >> derived indexqual clauses, with the hope that that would further >> reduce the added overhead for the commuted-clause case. However >> that crashed and burned when I found out that the extended-stats >> machinery punts when given a bare clause rather than a RestrictInfo. >> It could possibly be fixed to not do that, but it looks like the >> consequences would be extra lookups that'd probably cost more than >> we saved by omitting the RestrictInfo. Also, having RestrictInfos >> means that we can cache selectivity estimates across multiple >> calls. I'm not entirely sure how much that matters in this >> context, but it's probably not negligible.
> Is it reasonable to give ext-stats the option to receive either a > "plain" clause or a RestrictInfo, and if the former have it construct > the RestrictInfo and return it? No, I don't think it'd be sane to have ext-stats modify that data structure after-the-fact. Too much risk of trouble (he says while eyeing the GEQO machinery warily); plus, if we did it like that, we'd *definitely* be giving up the ability to cache and share cost/selectivity numbers between ext-stats and other places. > It seems a pity to waste effort to > cater for ext-stats, only to be used in the rare case where any > ext-stats actually exist ... most of the time, it'd be wasted effort. I'm not sure it's a good idea to design on the assumption that ext-stats are rare. I think they'll get more common over time. Right now that machinery is hardly built out at all, but it's coming. regards, tom lane