Re: pgsql: Extended statistics on expressions
От | Tomas Vondra |
---|---|
Тема | Re: pgsql: Extended statistics on expressions |
Дата | |
Msg-id | eae26b31-2d9b-1293-a3b0-a8be4820bea3@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: pgsql: Extended statistics on expressions (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: pgsql: Extended statistics on expressions
|
Список | pgsql-committers |
On 3/31/21 7:08 PM, Alvaro Herrera wrote: > On 2021-Mar-31, Tomas Vondra wrote: > >> Thanks for the report, I'll take a look. You're right this seems like an >> out-of-bounds access, but mcv_match_expression is only expected to be >> run on expressions we know are in the statistics (because we pick the >> statistics like that). Clearly, that does not happen here, not sure why. >> >> It's quite weird that we end up running textlike(), when the statistics >> is on (double precision, boolean) columns ... > > Uninitialized values somewhere? Maybe valgrind would help. > Unlikely, I've ran it through valgrind repeatedly, including right before commit (both on x86_64 and arm). FWIW I'm unable to reproduce it, so not sure what's going on. David, what configure option are you using? Anything special? It's a bit strange, because statext_mcv_clauselist_selectivity should only estimate "matching" clauses on the statistics. So how come this estimates such a complex expression using textlike(), when neither of those columns is text? It'd be interesting to know what's happening in the code after stat = choose_best_statistics(...); i.e. what clauses it considers "compatible" with the statistics and why. In fact, I wouldn't have expected the statistics to be used at all. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-committers по дате отправления: