Re: Postgres vr.s Oracle - Mailing list pgsql-advocacy
From | Jonah H. Harris |
---|---|
Subject | Re: Postgres vr.s Oracle |
Date | |
Msg-id | 36e682920812132034t13739039uaf35e4f77cb66785@mail.gmail.com Whole thread Raw |
In response to | Re: Postgres vr.s Oracle (Robert Treat <xzilla@users.sourceforge.net>) |
Responses |
Re: Postgres vr.s Oracle
Re: Postgres vr.s Oracle |
List | pgsql-advocacy |
On Sat, Dec 13, 2008 at 3:38 PM, Robert Treat <xzilla@users.sourceforge.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
pgsql-advocacy by date: