I'm trying a work-around on the "index on int8 column gets ignored by planner when queried by literal numbers lacking the explicit '::int8'" issue, and had hoped that perhaps I could create a functional index on the result of casting the pk field to int4, and mabye with a little luck the planner would consider the functional index instead. Here's what I'm playing with on 7.3.4:
social=# create table foo (id int8 primary key, stuff text);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'foo_pkey' for table 'foo'
CREATE TABLE
social=# create index foo_pkey_int4 on foo(int4(id));
CREATE INDEX
social=# explain analyze select id from foo where id = 42;
QUERY PLAN
------------------------------------------------------------------------ --------------------
Seq Scan on foo (cost=0.00..22.50 rows=1 width=8) (actual time=0.01..0.01 rows=0 loops=1)
Filter: (id = 42)
Total runtime: 0.15 msec
(3 rows)
social=# explain analyze select id from foo where id = 42::int8;
QUERY PLAN
------------------------------------------------------------------------ ------------------------------------
Index Scan using foo_pkey on foo (cost=0.00..4.82 rows=1 width=8) (actual time=0.02..0.02 rows=0 loops=1)
Index Cond: (id = 42::bigint)
Total runtime: 0.09 msec
(3 rows)
social=# explain analyze select id from foo where id = int4(33);
QUERY PLAN
------------------------------------------------------------------------ --------------------
Seq Scan on foo (cost=0.00..22.50 rows=1 width=8) (actual time=0.01..0.01 rows=0 loops=1)
Filter: (id = 33)
Total runtime: 0.07 msec
(3 rows)
Is this just a dead end, or is there some variation of this that might possibly work, so that ultimately an undoctored literal number, when applied to an int8 column, could find an index?
Thanks, JamesAdvertising
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
