Re: Introducing floating point cast into filter drastically changes row estimate - Mailing list pgsql-bugs

From Merlin Moncure
Subject Re: Introducing floating point cast into filter drastically changes row estimate
Date
Msg-id CAHyXU0ypsKL+UiwsR6uLhPpQPuOS_a+BnNcTgmAQ5Vh1Q+aP+w@mail.gmail.com
Whole thread Raw
In response to Re: Introducing floating point cast into filter drastically changes row estimate  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Introducing floating point cast into filter drastically changes row estimate  (Merlin Moncure <mmoncure@gmail.com>)
List 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 by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Introducing floating point cast into filter drastically changes row estimate
Next
From: "Kevin Grittner"
Date:
Subject: Re: BUG #7619: Query cost estimate appears to not use n_distinct setting