> A common problem is a table like this:
>
> create table test (info text, id int8 primary key);
> insert into test values ('ted',1);
> .. a few thousand more inserts;
> vacuum full;
> analyze;
> select * from test where id=1;
>
> will result in a seq scan, always, because the 1 by itself is
> autoconverted to int4, which doesn't match int8 automatically. This
> query:
>
> select * from test where id=1::int8
>
> will cast the 1 to an int8 so the index can be used.
>
>
Hey Scott, this is a little scary because I probably have a lot of this
going on...
Is there a way to log something so that after a day or so I can go back and
look for things like this that would be good candidates for optimization?
I've got fast enough servers that currently the impact of this problem might
not be too obvious, but I suspect that after the server gets loaded up the
impact will become more of a problem.
By the way, I must say that this thread has been very useful.
Matthew Nuzum | Makers of "Elite Content Management System"
www.followers.net | View samples of Elite CMS in action
[EMAIL PROTECTED] | http://www.followers.net/portfolio/
---------------------------(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
