Ed Loehr <pggeneral@bluepolka.net> writes:
> What I neglected to mention was that the planner was *choosing* the
> slower hashjoin plan over the much faster nested loop plan without any
> PGOPTIONS set or any postgresql.conf changes to enable_*, thus the
> motivation for a "thumb on the scales." After upping the number of
> shared buffers, it has begun choosing the smart plan 1-second plan,
Interesting. The estimated cost of indexscans is dependent on
shared_buffers, but not so dependent that I'd have expected it to make a
difference here. What were the EXPLAIN numbers you were getting, again?
regards, tom lane