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 | CAHyXU0ypsKL+UiwsR6uLhPpQPuOS_a+BnNcTgmAQ5Vh1Q+aP+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Introducing floating point cast into filter drastically changes row estimate (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Introducing floating point cast into filter drastically
changes row estimate
|
Список | pgsql-bugs |
On Wed, Oct 24, 2012 at 3:51 PM, Merlin Moncure <mmoncure@gmail.com> wrote: > 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)'? By the way, just in case it wasn't obvious, that was a very much tongue-in-cheek suggestion. I was just hoping that the final disposition of this problem isn't: 'there are some queries that are impossible to plan correctly'. Anyways, thanks for the help. merlin
В списке pgsql-bugs по дате отправления: