From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tony Capobianco <tcapobianco(at)prospectiv(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Oracle v. Postgres 9.0 query performance |
Date: | 2011-06-08 17:03:49 |
Message-ID: | 14544.1307552629@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tony Capobianco <tcapobianco(at)prospectiv(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-06-08 17:17:12 | Re: Oracle v. Postgres 9.0 query performance |
Previous Message | John Williams | 2011-06-08 16:37:09 | Re: Set of related slow queries |