Comments on: Oracle and Postgres Redux

By: www.simononsoftware.com

www.simononsoftware.com — Thu, 08 Jan 2009 15:53:19 +0000

By: Mike Johnson

Mike Johnson — Thu, 11 Dec 2008 21:06:11 +0000

Yeah, I saw that. Now I feel bad. :-)

Having just got out of the Marine Corps, I’m used to giving people a good ribbing for just about anything. Sometimes I forget that people will actually get upset.

I will follow my 12 steps more carefully.

http://www.robichaux.net/blog/2008/01/12step-program-for-recovering-marines.php

Although, he should take some comfort in the fact that I mentioned him because there’s no other source as knowledgeable as he is on performance. Every time I have some weird problem with Oracle, I google it. He’s almost always the first result, and his articles are always helpful and well constructed.

By: Richard

Richard — Thu, 11 Dec 2008 19:45:08 +0000

Well, the DBA guy with the weird picture has since changed his profile pic.
I hope you’re comfortable with the soul-searching you inadvertently hoisted on him. (i would be)

By: Emanuel

Emanuel — Thu, 11 Dec 2008 15:44:11 +0000

Adding to my first comment.
I think it was interesting if you can show the querys where oracle have better or similar runtime, just for curious …
could it be?

By: JD

JD — Thu, 11 Dec 2008 09:17:44 +0000

While your graph is pretty, it’s invalid. You’re dealing with completely independent data points, so you should be using a bar graph, not a line graph, which should only be used for graphing a series of continuous data points.

Also, I’m curious what you’re going to say about terracotta, as you appear to be using it as a cache, when it’s not designed for that. Terracotta is a distributed shared memory system. If you want distributed caching, you should be using something like memcache.

By: Greg Smith

Greg Smith — Thu, 11 Dec 2008 07:15:16 +0000

Sure, I get that, just pointing that even a few minutes of basic tuning might get you a nice improvement. The default PostgreSQL configuration is really awful, because of kernel restrictions actually. It’s setup to work even on something like a stock Linux install that only allows 32MB of shared ram to be allocated, whereas Oracle just flat out tells you need a larger SHMMAX to support any reasonable SGA size as part of the install instructions.

Also, above I saw you mention doing a VACUUM FULL ANALYZE. The FULL part of that isn’t needed–if you do regular VACUUM often enough or have autovacuum on, you shouldn’t even need to use FULL. And FULL can cause some problems with your indexes becoming slower than they should be; a full vacuum is not something you should ever need to do, except if you’re deleting a large quantity of information and need the space back. Just a random aside, it shouldn’t have any impact on what you did.

By: Anonymous

Anonymous — Thu, 11 Dec 2008 02:20:12 +0000

Materialized views in postgres are fairly well documented. [http://jonathangardner.net/tech/w/PostgreSQL/Materialized_Views]

By: Mike Johnson

Mike Johnson — Thu, 11 Dec 2008 01:02:59 +0000

I’m running both on my development workstation one at a time. An Ubuntu Hardy install 2.40Ghz dual core, 2 gig RAM with a single SATA drive.

Of course, Oracle would benefit some what more that Postgres by keeping the logs on separate drive. Postgres keeps just about everything in the table and seems to be well served by a RAID configuration.

But I think because there’s no write activity the log location wouldn’t make much of a difference for this experiment.

By: Mike Johnson

Mike Johnson — Thu, 11 Dec 2008 00:52:17 +0000

You’re right of course. My intention was to see what little I could get away with to beat Oracle’s times. It wasn’t a lot. Of course, I tweaked our production server pretty extensively.

By: Greg Smith

Greg Smith — Wed, 10 Dec 2008 23:35:41 +0000

If you didn’t do any configuration optimization for PostgreSQL, you might get a nice boost just from tweaking a few parameters. The default configuration is only appropriate for a system with about 128MB of RAM, it’s “optimized” for working out of the box on a wide range of systems rather than performance.

There’s a fairly focused list at http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server that goes over where to start. For what you’re doing, touching shared_buffers, effective_cache_size, and work_mem should be sufficient to improve things quite a bit with only a few minutes of effort. Add checkpoint_segments if you care about speeding up write-intensive things, too. Getting those basics right gets you more bang per time spend tuning than trivia like recompiling for your architecture.