Tony Capobianco <tcapobia...@prospectiv.com> writes:
> Well, this ran much better. However, I'm not sure if it's because of
> set enable_nestloop = 0, or because I'm executing the query twice in a
> row, where previous results may be cached. I will try this setting in
> my code for when this process runs later today and see what the result
> is.
If the performance differential holds up, you should look at adjusting
your cost parameters so that the planner isn't so wrong about which one
is faster. Hacking enable_nestloop is a band-aid, not something you
want to use in production.
Looking at the values you gave earlier, I wonder whether the
effective_cache_size setting isn't unreasonably high. That's reducing
the estimated cost of accessing the large table via indexscans, and
I'm thinking it reduced it too much.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
