On 21 July 2017 at 20:00, Tom Lane wrote:
>> I have, however, decided not to volunteer to be the one who works on
>> that project.
>
> Me either. Any one of these things would require a *lot* of work in
> order to have a coherent feature that provided useful behavior across
> a bunch of differen
Robert Haas writes:
> Another very similar (but possibly easier) case is:
> select * from pgbench_accounts where aid = 1.0;
> This will use a sequential scan rather than an index scan, because the
> query optimizer doesn't know that the only integer for which =(int4,
> numeric) will return true
On Fri, Jul 21, 2017 at 10:33 AM, Tom Lane wrote:
> But the bigger picture is that doing something that helps to any
> useful extent would require a really substantial amount of new,
> datatype- and operator-specific knowledge that doesn't exist in the
> system today. And as Craig noted, applying
Tatsuo Ishii writes:
> Currently following query does not use an index:
> test=# explain select * from pgbench_accounts where aid*100 < 1;
> While following one does use the index.
> test=# explain select * from pgbench_accounts where aid < 1/100;
> Is it worth to make our optimizer a lit
On 21 July 2017 at 07:11, Tatsuo Ishii wrote:
> Currently following query does not use an index:
>
> t-ishii@localhost: psql -p 5433 test
> Pager usage is off.
> psql (9.6.3)
> Type "help" for help.
>
> test=# explain select * from pgbench_accounts where aid*100 < 1;
>
Currently following query does not use an index:
t-ishii@localhost: psql -p 5433 test
Pager usage is off.
psql (9.6.3)
Type "help" for help.
test=# explain select * from pgbench_accounts where aid*100 < 1;
QUERY PLAN
--
