Re: Oracle v. Postgres 9.0 query performance

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

In response to

Responses

Browse pgsql-performance by date

  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