Re: Introducing floating point cast into filter drastically changes row estimate
| От | Merlin Moncure |
|---|---|
| Тема | Re: Introducing floating point cast into filter drastically changes row estimate |
| Дата | |
| Msg-id | CAHyXU0yLQpshj5mgF_2zzjyKqmrniMqhzrbpBd7SZ1MD2UO=dQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Introducing floating point cast into filter drastically changes row estimate (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Introducing floating point cast into filter drastically
changes row estimate
|
| Список | pgsql-bugs |
On Wed, Oct 24, 2012 at 3:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Merlin Moncure <mmoncure@gmail.com> writes: >> Yeah -- I have a case where a large number of joins are happening that >> have a lot of filtering based on expressions and things like that. > > Might be worth your while to install some indexes on those expressions, > if only to trigger collection of stats about them. Not practical -- these expressions are all about 'outlier culling'. It's just wasteful to materialize indexes for stastical purposes only. Anyways, in this case, I just refactored the query into a CTE. Hm -- what if you could flag a table dependent expression for being interesting for statistics? Or what about planner hints for boolean expressions (ducks) ... 'likely(boolexpr)'? merlin
В списке pgsql-bugs по дате отправления: