<snip>
> What's likely happening is that the queries that are choosing the right
> plan (i.e. the other queries) are such obviously bad candidates for a
> seq scan that they still get an index scan. It might be that as you
> increase the % of the table being read by those other queries that they
> might switch to a seq scan too soon for your setup.
>
Agreed. This seems to be the "better of all" solution, but, in our case,
it's not that feasible. We can't reproduce the load, now, on a spare
and identical machine and begin testing differente parameters.
On the other side, we just can't restart the server to endure the proper
values are loaded and provide a standard reference to any tuning...
> I'm assuming you've read the tuning guide here:
>
> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
>
Yes. I've read them. That's why I asked if we can deal with it in
another way (sending an enable_seqscan = false) without creating
colateral damage to other parts of the program that use the
same (pooled) connection
> And upped shared buffers, effect_cache_size, etc...
>
Shared buffers was set up a couple weeks ago. Didn't change the
default values to planner-specific variables. I guess the random page
cost is set to 4. So, I think a bit weird a seq scan is choosen, after all
(yes, we do constant vacuum analyze).
> random page costs of 1.0 to 1.4 make sense for certain setups with lots
> of RAM and medium to small datasets that can (mostly) fit in memory.
> On our machine with 2G ram at work, that works out to about 1.2 to 1.3
> as optimal.
>