[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-performance
Subject:    Re: [PERFORM] General key issues when comparing performance between PostgreSQL and oracle
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2013-07-17 4:51:36
Message-ID: 3402.1374036696 () sss ! pgh ! pa ! us
[Download RAW message or body]

Scott Marlowe <scott.marlowe@gmail.com> writes:
> On Tue, Jul 16, 2013 at 10:51 AM, Brian Fehrle
> <brianf@consistentstate.com> wrote:
>> I'm working on performance tuning a host of queries on PostgreSQL 9.2 from
>> an application, each query having its own issues and fixes, however from
>> what I understand this application runs the exact same queries on the exact
>> same data in half the time on oracle and SQL server.
>> 
>> It's worth noting that the queries are not that good, they have issues with
>> bad sub-selects, Cartesian products, and what looks like bad query design in
>> general, so the blame isn't completely with the database being slow, but I
>> wonder what makes oracle preform better when given not-so-great queries?

> Fact is that if the query can be made better, then you get to do that.

Another point worth making here: we often find that ugly-looking queries
got that way by being hand-optimized to exploit implementation
peculiarities of whichever DBMS they were being run on before.  This is
a particularly nasty form of vendor lock-in, especially if you're
dealing with legacy code whose current custodians don't remember having
done such hacking on the queries.

I'm not necessarily claiming that your particular cases meet that
description, since you're saying that the queries perform well on both
Oracle and SQL Server.  But without details it's hard to judge.  It
seems most likely from here that your first problem is a badly tuned
Postgres installation.

			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
[prev in list] [next in list] [prev in thread] [next in thread]