Re: How to track down inconsistent performance?

Ron Snyder <snyder(at)roguewave(dot)com> writes:
>> affect that). I would think that a seqscan would be faster for this.
>> I would definitely think that the planner would think so --- are you
>> forcing enable_seqscan off?

> Forgot to answer this-- no, we're not forcing it off. Maybe we need to
> force it to use a seqscan for this query?

It would be interesting to try that just for comparison purposes.
I'd like to know the difference in the planner's cost estimate,
as well as the actual runtime.

Your results do make it look like the difference between "fast" and
"slow" cases is just whether the table and index data are in disk buffer
cache or not. What shared_buffers setting are you using for Postgres?
Have you tried experimenting with other values? What's the total RAM
in the box? The ultimate answer might just be "you need to buy more RAM" ...

regards, tom lane