Have I b0rked something? Slow comparisons on "where x in (...)"

Postgres version 8.0.9 on Solaris 2.8. I know it's old but...

I have a table with a million rows.

I need to select data from this table based on an indexed column; I need
to select 600 possible values from the column, returning around 24,000
rows of data.

In perl I have a hash which has 600 key values in it.

So I did:

"select stuff from table where index_key in (" .
join(",",keys %hash) . ") AND non_index_row in ('xyz','abc','def')

And in the perl
while(fetch())
{
do_stuff
}

This resulted in a query string which executed in 12 minutes. If I
did an "explain" on the query string then I can see it was being expanded
to 600 OR statements
where (index_key = 1) OR (index_key = 2) OR .....

Now as an alternative option I did
select stuff from table where non_index_row in ('xyz','abc','def')
and in the perl
while(fetch())
{
next unless $hash{$_->{index_key}};
do_stuff
}

To me this should be slower since we're selecting more rows, throwing
the data back to the perl and then discarding values I didn't want.

Imagine my surprise when the result took 3 minutes to execute.

Have I broken something, somewhere? Or are IN comparisons really that
slow?

For what it's worth, a simple

explain select count(*) from table where index_key in (1,2,3,4,....)

uses the index up until 156 values but then switches to sequential scan
when there are 157 or more values in query.

Any thoughts? I fear my poor tuning attempts may have caused other
slow downs!

--

rgds
Stephen