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

From Tom Lane
Subject Re: Introducing floating point cast into filter drastically changes row estimate
Date
Msg-id 6962.1351106799@sss.pgh.pa.us
Whole thread Raw
In response to 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
Merlin Moncure <mmoncure@gmail.com> writes:
> The following query runs fine: it estimates the returned rows pretty wel:
> postgres=# explain analyze  select * from foo where i > 100 and i < 10000;

> ...but if you introduce a floating point cast, it drastically changes
> the returned rows (why?):

> postgres=# explain analyze  select * from foo where i::float8 > 100
> and i::float8 < 10000;

The planner has stats about "i", but none about "i::float8", so you're
getting a default estimate in the second case.  It does, however,
realize that you're applying a range restriction condition to
"i::float8", and the default selectivity estimate for that is
intentionally pretty small.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Greg Hazel
Date:
Subject: Re: BUG #7620: array_to_json doesn't support heterogeneous arrays
Next
From: Merlin Moncure
Date:
Subject: Re: Introducing floating point cast into filter drastically changes row estimate