Re: very slow selects on a small table

Brian Cox <brian(dot)cox(at)ca(dot)com> writes:
> these queries are still running now 27.5 hours later... These queries
> are generated by some java code and in putting it into a test program so
> I could capture the queries, I failed to get the id range correct --
> sorry for wasting your time with bogus data. Below is the EXPLAIN output
> from the 4 correct queries. I can't tell which one is being executed by
> PID 7397, but the query plans, except the last, do look very similar. In
> any event, as I mentioned, all 4 are still running.

Strange as can be. Can you do an EXPLAIN ANALYZE on just the IN's
sub-select and confirm that the runtime of that is reasonable? I'd
be interested to know how many rows it really returns, too.

One thing that strikes me is that the cost estimates seem a bit on the
low side for the rowcounts. Are you using nondefault planner cost
parameters, and if so what?

regards, tom lane