Re: Postgres vr.s Oracle

On Sat, Dec 13, 2008 at 3:38 PM, Robert Treat
<xzilla(at)users(dot)sourceforge(dot)net> wrote:
> Curious, but does your "well tuned" system include query hints?

No.

> I've certainly seen cases where Oracles hinting system allowed them to get to places that
> Postgres couldn't get to, but without hinting things tend to be much closer
> (not necessarily even; it still has other advantages like advanced sql
> syntax) In my mind this is an argument for adding query hinting to postgres,
> but I hate to even mention that idea :-)

I've always agreed with adding hints... but as we all know, that's a
different topic altogether.

> I think you have misjudged the argument, which would be (IMHO) more accurately
> stated that given this projects resources, we will get better performance by
> leveraging os/filesystem improvements rather than circumventing them. One
> such example is a patch for doing auto-alignment of columns at the disk layer
> for optimal performance. This patch is relatively simple (for this
> discussion), yet the idea has been around for years; if we can't knock that
> out, do you really think we have the resources to move towards direct
> hardware interaction?

I understand the resource limitation. That's not the problem. The
problem, from my point of view, is that there's a near-constant
rejection against the possibility of using fairly well-known and
greatly accepted implementations. Examples are the "Features We Do
Not Want" in the TODO, and the "Why don't you use threads, raw
devices, async-I/O, <insert your favorite wizz-bang feature here>?"
section of the FAQ. For examples, we use threads and async I/O.
Threading has been supported by every major OS for how long now? How
buggy is it really? A heck of a lot of stuff is written using threads
and it runs continuously and under heavy load without a single
problem. Asynchronous I/O... Oracle8i supported it in 1999 (and in
earlier versions if you knew how to enable it). My point is simply
that this isn't new or untested technology, and that we should at
least be open to it. But when our own FAQ calls threading buggy,
crash-prone, overly complex, and not worth it from a performance
standpoint, it makes a lot of people question the amount of Postgres
community experience related to performance engineering. Similarly,
it makes it difficult for those of us with experience using these
technologies to even have discussions about them on-list.

> Well, there is something to be said for having a database system so complex
> that properly tuning it can't be done even by experienced users. Postgres is
> an order of magnitude easier to configure (imho) and we still get beat up for
> it.

Well, people will always find something to complain about with
Postgres, Oracle, and every other thing :)

Oracle has tons of options because no workload can be characterized by
a small number of knobs. If you know how something needs to work,
nine times out of ten Oracle has a way for you to alter the system to
make it work that way. Yes, that does make it more complex, and I'm
not denying that at all. My point was simply that individuals without
extensive experience tuning Oracle and performing scientific
benchmarks aren't generally the best people to make valid overall
comparisons. My main concern is based on talking to people at PG
conferences who put far too much faith and belief into results derived
from bad benchmarks.

Again, I do not want this thread to be an argument of Oracle vs.
Postgres. I just wanted to say that we should look at benchmarks
which have some resemblance of scientific validity before simply
passing them out or believing in them ourselves. This is open source
and believing in our own benchmarketing is just going to hurt us
long-term.

-Jonah