Slashdot Mirror

You seem certain that PostgreSQL can use more than one index per query. Well, a cursory search on Google comes up with this page. The "Red Hat Database" is basically PostgreSQL (I think!), and a little way down this page you can see this comment:

"Note that a query or data manipulation commands can only use at most one index per table."

Here's another link which seems to confirm this.

I believe I have seen comments somewhere regarding experimental support for multiple indexes in queries in PostgreSQL, but I am interested as to whether this is a mature technology, rather than new and/or experimental, or limited to special cases.

Thanks,

-Neil

SQL standard says that "table1" should not be equal to Table1 (ie "select column1 from Table1"). MySQL doesn't respect this

MySQL is further from PostgreSQL here. The standard specifies that identifiers which are not double quoted should be folded to upper case. MySQL provides no case folding which breaks compatibility with the standard pretty clearly. PostgreSQL violates the standard by folding to lower case (as opposed to upper) which is compatibible with the standard in 99%+ of real world applications (though I am a big proponant of providing the option of folding to upper).

MySQL supports all operators in the core.

Right... Except that some (like ||) do different things than the spec says unless you change the mode to ANSI mode. This leads to *very* unportable code.

Here are some areas under active development in PostgreSQL at the moment:

SQL/PSM standards support.

SQL/MED standard support

As for SQL-2003 compliance, you can see the list of supported and unsupported features at http://www.postgresql.org/docs/8.0/interactive/fea tures.html

Unless you can point to specific SQL-2003 features that MySQL supports properly and PostgreSQL does not, I call FUD.

• People who want GPL can have GPL for open source projects, or applications that are not redistributed.
• People who want a more traditional license, with freedom to redistribute products using MySQL without opening source, can have that too.

Why do you call this doubly accommodating arrangement "crap"?

Sure, PostgreSQL's BSD license is less restrictive, but why should MySQL (or anyone else) have to use that, if they don't want to? (The GPL is framed to guarantee certain freedoms to users; the BSD license grants complete freedom to those making products from the source, but does not protect users at all. I thought everyone had figured this out by now?)

Also, don't forget that each core PostgreSQL developer works at a different company. It'd be really hard to damage the core devs just by damaging one company.

> they could try and hire all the main developers or something

Right on, yup, that's about the only way they could do that - by hiring Tom Lane or some of the other gurus. But they can't "buy PostgreSQL". There have been some interesting discussions on this on the pgsql-advocacy list recently as well.

> And I'm glad of that as Postgres is my favorite rdbms.

Same here! 3.5 million records and cranking along; PostgreSQL is meeting RubyForge's needs very nicely.

I haven't tried ibFirebird yet, and for most things it's not really up to PostgreSQL's level, but I have a peer who uses it with great success. It's one of several databases (all mentioned here are included) with features and syntax explicitly designed to make conversion from Oracle easy.

Besides, "not up to PostgreSQL's level" is massive overkill for most projects.

In Real Life(tm), even SQLite is overkill for most projects: SQLite is quite capable, where a SQL interface to flat files and perhaps some rudimentary indexing would be more than enough for 90% of what's out there.

It's not PostreSQL community, but it is EnterpriseDB:
http://archives.postgresql.org/pgsql-advocacy/2005 -08/msg00153.php

I guess EnterpriseDB doing this, partnering up with SCO for aparently same
reasons as MySQL AB, makes them bad? Oh, maybe not, because they are a PostgreSQL
company? Huh?

Not going to fight fire with fire.. but really.. :(

The BSD-licensed PostgreSQL is actually *more* powerful than MySQL. Depending on your needs, it's worth looking into.

there are others, but Postgre is MySQL's primary FLOSS competitor.

I s'pose that us "fans of Linux and other open source software" have a get out clause in that we could take MySQL's existing codebase under the GPL and develop it the way we want, free from SCO influence.

Of course it'll probably turn out that SCO wrote MySQL at some point and we'll all have to start using postgres instead.

BTW: I think the "important bit of software" made by Innobase in the article is the InnoDB table storage engine (cf. this slashdot article).

Postgres (last I checked) preferred to let the OS do the data-caching. Thanks, but no thanks.

And no 64-bit version [of Postgres] (though I've read a few people have managed to compile one, I wouldn't trust it unless Postgres gave it the thumbs up).

Maybe, maybe not. It's nice to see a proposed release month, which was not mentioned in the other article. This was a welcome and informative headline in my RSS reader.

...And just one month after I switched to PostGres for those features!

I call your bluff. Here's the entire, unedited PostgreSQL license (source their website):

PostgreSQL Database Management System (formerly known as Postgres, then as Postgres95)

Portions Copyright (c) 1996-2005, The PostgreSQL Global Development Group

Portions Copyright (c) 1994, The Regents of the University of California

Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Where's this advertising clause you speak of? Or did you hear "BSD license" and drag out a decade-old complaint that's long since been addressed? That's as bad as people complaining that MySQL doesn't support transactions, except that's true under certain circumstances whereas your criticism is completely unfounded.

MySQL days are over. Let YourSQL be PostgreSQL. Huh! Sun will choose PostgreSQL

It's fixed in the upcoming 8.1 version, now in beta.

Are you sure?

I didnt see it in the release notes... but I did see reference to a fix being held for 8.2. See: http://momjian.postgresql.org/cgi-bin/pgpatches_ho ld

I hope it is not deferred until 8.2... sigh.

What you want is PLJava, which is released and functional code:

http://gborg.postgresql.org/project/pljava/projdis play.php

PLJ was more like a first try, and I don't think it's being maintained.

OS Support: PostgreSQL ~= MySQL; postgres came a long way, e.g. there's now a stable Windows version.

I just wish they would figure out a way to get a fully functioning Unicode version for Windows. It sounds like they threw the baby out with the bath water. See their FAQ for their detailed description: http://pginstaller.projects.postgresql.org/faq/FAQ _windows.html#2.6

I think the FAQ needs clarification. They say "Unicode is not properly supported on Windows, and therefore cannot be used.". My impression is that the reality is more like, "PostgreSQL uses UTF-8, and this encoding is not fully supported on Windows the way they would like. Windows (NT, 2000, XP, 2003) does support UTF-16 natively."

There are already too many PostgreSQL players!

PostgreSQL
Pervasive
EnterpriseDB
and likely many more...

Hint: PostgreSQL. If you play with proprietary vendors, you get proprietary vendor games.

The article mentioned MySQL so it's only fair to mention that EnterpriseDB Secures $7 Million in Venture Capital Financing for their postgresql-based database. They share many of their innovations back to the community.

Wow, I've been waiting for this topic to show up for, what, six years now? :)

What you want is a Davis Instruments station. These stations hook up, via serial cable, to any PC. If you're running some form of *nix, I highly recommend the Device::WxM2 Perl module. I've written various collection daemons that use WxM2 to pull weather data from the station and store it in RRD format or in a PostgreSQL database. I even wrote an AGI script that allows people calling my Asterisk PBX to hear the latest weather data. I also wrote a handy widget for Konfabulator that lets you watch the weather on your Mac/PC desktop in real-time.

Shameless plug: if you decide that the Davis station is right for you, stop by my employer's website, where we have a variety of Davis Instruments choices.

One word of advice: we sell cheaper stations than the Davis models but if you are planning on putting this up on a roof and leaving it for 5+ years, you really want to go with a quality peice of equipment, not a Radio Shack toy that will disintegrate after a year in the sun.

Questions? Ask and I'll be glad to answer.

Chris

Yes.

For master/slave, use slony.

http://gborg.postgresql.org/project/slony1/projdis play.php

For multi-master, use pgcluster.

http://pgfoundry.org/projects/pgcluster

No you don't. Use a filesystem which supports snapshots, like UFS2, and take a snapshot of the filesystem. Back up the snapshot. You will have a "broken" database backup, but since PostgreSQL does logging and all sorts of other ACID-ish things, it can recover from that just fine. You'll just lose whatever transactions were pending at the time the snapshot was taken. Par for the course: you'd lose them doing pg_dump too.

Well, Postgresql.org contains detailed instructions on how to install their database on OpenServer. So they are actively supporting SCO. Can we trust them?

A real database user that needed to hold a value of 300 would not use a column type that has a range of 0 to 255 or -127 to 127, since they would have read the page on choosing types. I guess *nix isn't a real operating system because it will let you destroy your system by doing things like "rm -rf / path/to/file"? You meant for that space to be there, right? :)

Anyway, from http://dev.mysql.com/doc/mysql/en/numeric-types.ht ml, that will generate a warning if you do an update or a multi-row insert (why not in a single insert, I can't really justify):
When asked to store a value in a numeric column that is outside the column type's allowable range, MySQL clips the value to the appropriate endpoint of the range and stores the resulting value instead.
Conversions that occur due to clipping are reported as "warnings" for ALTER TABLE, LOAD DATA INFILE, UPDATE, and multiple-row INSERT statements.

BTW - Postgres isn't a real database, either, in the example of storing 32767+1 in a smallint:
http://www.postgresql.org/docs/7.4/interactive/dat atype.html
Some of the operators and functions (e.g., addition and multiplication) do not perform run-time error-checking in the interests of improving execution speed. On some systems, for example, the numeric operators for some data types may silently cause underflow or overflow.

PostgreSQL?

Where else can you load up a 50+ database cluster and not have to shell out a fortune on licensing fees?

PostgreSQL

Your [sic] a fool if you think that postgres can replace Oracle.

Oh, my a fool, right?

Most large organizations are never going to trust something without a service agreement.

Indeed. That's why they buy professional support I guess... Seriously, is it really that hard to use Google for God's sake? I'm not even going to read the rest of your troller posting.

Let's recap: The only comparison in this slashdot article is a reference to a six year old comparison referenced in Slashdot. That's it. There is no comparison going on here.

Here's my comparison: starting somewhere in version 4.x, mySQL moved much closer to the SQL standard and other SQL implementations (MS, Sybase, Oracle et al.) than PostgreSQL, particularly in respect to stored procedures, and particularly when being programmed in SQL. (ironic, eh?)

I have recently checked out the latest versions of mySQL and I am impressed. As for PostgreSQL, it certainly has its strengths, but portable stored procedure support is not among them. Do a quick search of the table of contents for "stored" in the PostgreSQL documentation. Yes, it's buried there somewhere in the documentation but that in itself is telling. The earlier version of PostgreSQL was just plain different. My brief perusal of the current documentation suggests that it hasn't changed in this respect.

Reading a bit more, I see it hasn't. Input variables for PostgreSQL don't have names; they are numbered: $1 for the first argument, $2 for the second, etc. The only other database language I've seen this is 4th Dimension but that's for procedural scripts, not (the equivelant) of SELECT statements.

As an SQL programmer, trying to work with PostgreSQL was sheer hell. As for scripting in other languages, I wouldn't know. It seems to me that the PostgreSQL designers care little for common SQL coding.

I took a job porting a non-SQL database to PostgreSQL. The existing small IT staff chose PostgreSQL. I was hired as an SQL guy because none of them had any real experience with SQL. You should be able to see where this is going. Without going into details, the results were devastating for me.

It seems you're not completely correct about the real reasons, since cPanel does include PostgreSQL configuration tools...

If you truly believe Unicode support is fundamentaly broken in some way then why not help the project out by filing a bug report with a specific example that demonstrates the problem?

The instructions for filing a bug report are at:
http://www.postgresql.org/docs/current/static/bug- reporting.html

PostgreSQL has had updatable views for quite a while now (at least as far back as 7.2) through the Rule System. The rule system is powerful enough to allow you to update ambigous insert or update statements in a view that may join across multiple tables. One INSERT/UPDATE statement can be rewritten into multiple updates or inserts into multiple tables.

There may be other things that MS-SQL can do that PostgreSQL can't (I haven't used MS-SQL so I have no knowledge there), but I just wanted to clear that one up.

As for vacuuming, it hasn't really bothered me. Especially now that the autovacuum daemon does the work very efficiently for you. And before that, a cronjob always did the job.

You mean a Microsoft installer file named something like postgresql-8.0.msi? A single, redistributable file like that?

Looks like there's a file just like that in the Win32 zip download for PostgreSQL. Just bundle up the appropriate install file with your app and you're set.

Available via FTP and bittorrent for your convenience. Admittedly, it wouldn't have helped you two years ago, but it's been there for at least the last six months or so.

What was that MSDE advantage again?

- INSERT is very slow (about 3x slower compared to MySQL/InnoDB) for my dataset. The "answer" is to use the COPY command or disable your indexes/FK's which is f*cking lame since you loose all your relational integrity. I was willing to trade off performance for disaster prevention (system crash, power failure, etc) by disabling WAL, but you can't actually do that.

- The OSS tools available aren't as good for postgres as they are for MySQL. I've yet to find anything as nice or complete as phpmyadmin for Pg or something that supports schema's for ER Diagrams. Frankly, I'm sick and tired of designing my DB in vim.

- Having to run vacuum all the time to help the query optimizer figure things out. Why this doesn't happen automagically in the background without me having to worry about it is beyond me.

- In general, I find the documentation on mysql.com superior to on postgresql.org, but #postgresql more then makes up for it.

At least Postgres had the nice type system already to be extended. As for the spatial indexes PostGIS has GiST-based R-Tree spatial indexes.

Note this is not ideal and the PostGIS community is trying to scare up funds for a couple of mad finns (Oleg and Teodor) to fix up Postgres with the required concurancy support for GiST and row level locking.

http://www.directionsmag.com/article.php?article_i d=891
http://archives.postgresql.org/pgsql-hackers/2005- 06/msg00294.php

Actually if you wanted to actually speed things up implementing row level locking would help everyone .

Potgres knows where it needs to improve, support the mad hackers.

Do you know MySQL has had transactions for years now? And SAVEPOINT transactions (like Postgres, I believe). And views in 5.0. The table-locking engine you're thinking of (MyISAM) hasn't been current for maybe 4 years. If you can't handle 100 users at once blame your design, not MySQL -- MySQL powers Slashdot :)

I am outraged with MySQL AB after I learnt they do business with SCO. As a result, I plan to migrate my website's databases from MySQL 4.1 to PostgreSQL 8.0/8.1, and I concentrate on PostgreSQL support in my software projects. MySQL is wrong if they believe they can have the support of the free/libre open-source software communities and have relations with SCO at the same time. PostgreSQL is an advanced object-relational database management system which offers great programmability through its native programming language PL/PgSQL, as well as through several other language bindings (for PHP, Java, Perl, even sh). PostgreSQL is BSD-licensed and supported by a community of free software developers, while MySQL is supported by a corporation, MySQL AB, which sells proprietary licenses.

SCO UnixWare ships with Postgres. And why wouldn't they? All MySQL is doing is updating it's support for SCO products. Why is that bad?

From the horse's mouth:

> Ned,
>
> Actually, SCO has supported us for years. They may even have contributed
> patches. Their attorneys may be evil incarnate, but their technicians are
> friendly and skilled.
>
> I notice the article doesn't mention that the last 6 versions of UnixWare have
> included PostgreSQL ...
>
> --
> -Josh Berkus
> Aglio Database Solutions
> San Francisco

Source: pgsql-advocacy@postgresql@org
URL: http://archives.postgresql.org/pgsql-advocacy/2004 -06/msg00141.php

Actually, PostgreSQL is not partnering with SCO. Rather SCO has done a deal with EnterpriseDB who produce their own DB which is a modified version of PostgreSQL. So, while EnterpriseDB has done deals with both SCO and the PostgreSQL group, that one step removal is quite important.

see Here.

...is the reason why I switched from MySQL a while back to Postgres. At the time, although MySQL still had a version licensed under the GPL, the link to it was buried in the site. What was a lot easier to find was the commercially licensed version, which they had links to/info about slathered all over the site. This caused me to worry that eventually the GPL licensed version would disappear entirely.

Although Postgres is unfortunately a bit bigger, (the elephant isn't its mascot for nothing ;-)) it's a fantastic db and is enormously scalable. The best part is that legally it also uses open source's underdog, the BSD license.

It is unfortunate that MySQL AB have shown such lack of vision in the past couple of years...but methinks they're probably about to find out that commercialistic shortsightedness carries its' own reward:- Eventual irrelevance.

So long, My SQL. We liked you when you were good, but nothing lasts forever...

According to the FAQ, it's POST-gress-cue-ell. Other pronunciations include "POST-gress," "Pee GEE," "POST-gress-equal" and "Oracle Killer." Some people get really annoyed when you try for any of the pronunciations of "Postgre" because it reminds them of an ogre-like creature spouting bits of postmodern gibberish.

You can find tons of quality hosting companies. http://www.postgresql.org/support/professional_hos ting Why switch to Linux when you can find tons of stores selling computers with Windows already installed?!

Some people saying talking about 'the open-source' community switching to PostgreSQL because of this; that's ridiculous seeing as PostgreSQL has already adopted it's product to SCO's OpenServer. They even have a FAQ about it on their site: http://www.postgresql.org/docs/faqs.FAQ_SCO.html Besides, MySQL's code is still GPL and it's still more widely deployed on web hosting companies so it would be very inconvenient to drop MySQL support for PostgreSQL.

To move it all to PGSQL

The last thing I need is for SCO to come knocking saying their code is in my damn database. It was bad enough that they tried to steal my OS, now the data on top it isn't even safe.

So I'm being speculative if not pretentious but that doesn't change the fact that I'm serious about migration. I'm getting out while MySQL is still portable to PG.

Just use PostgreSQL and everyone will be happier.

http://www.postgresql.org/about/

PostgreSQL is a powerful, open source relational database system. It has more than 15 years of active development and a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness. It runs on all major operating systems, including Linux, UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, SunOS, Tru64), BeOS, and Windows. It is fully ACID compliant, has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL92 and SQL99 data types, including INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, and TIMESTAMP. It also supports storage of binary large objects, including pictures, sounds, or video. It has native programming interfaces for C/C++, Java, Perl, Python, Ruby, Tcl, ODBC, among others, and exceptional documentation.

An enterprise class database, PostgreSQL boasts sophisticated features such as the Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (savepoints), online/hot backups, a sophisticated query planner/optimizer, and write ahead log for fault tolerance. It supports international character sets, multibyte character encodings, Unicode, and in is locale-aware for sorting, case-sensitivity, and formatting. It is highly scalable both in sheer quantity of data it can manage and and in the number of concurrent users it can accommodate. There are active PostgreSQL systems in production environments that manage in excess of 4 terabytes of data. Some general PostgreSQL limits are included in the table below.
Limit Value
Maximum Database Size Unlimited
Maximum Table Size 32 TB
Maximum Row Size 1.6 TB
Maximum Field Size 1 GB
Maximum Rows per Table Unlimited
Maximum Columns per Table 250 - 1600 depending on column types
Maximum Indexes per Table Unlimited

PostgreSQL has won praise from it's users and industry recognition, including the Linux New Media Award for Best Database System and three time winner of the The Linux Journal Editors' Choice Award for best DBMS.
Featureful and Standards Compliant

PostgreSQL prides itself in standards compliance. Its SQL implementation strongly conforms to the ANSI-SQL 92/99 standards. It has full support for subqueries (including subselects in the FROM clause), read-committed and serializable transaction isolation levels. And while PostgreSQL has a fully relational system catalog which itself supports multiple schemas per database, its catalog is also accessible through the Information Schema as defined in the SQL standard.

Data integrity features include (compound) primary keys, foreign keys with restricting and cascading updates/deletes, check constraints, unique constraints, and not null constraints, all of which are deferrable.

It also has a host of extensions and advanced features. Among the conveniences are auto-increment columns through sequences, and LIMIT/OFFSET allowing the return of partial result sets. PostgreSQL supports compound, unique, partial, and functional indexes which can use any of its B-tree, R-tree, hash, or GiST storage methods.

GiST (Generalized Search Tree) indexing is an advanced system which brings together a wide array of different sorting and searching algorithms including B-tree, B+-tree, R-tree, partial sum trees, ranked B+-trees and many others. It also provides an interface which allows both the creation of custom data types as well as extensible query methods with which to search them. Thus, GiST offers the flexibility to specify what you store, how you store it, and the ability to define new ways to search through it --- ways that far exceed those offered by standard B-tree, R-tree and other generalized search algorithms.

GiST serves as a foundation for many public projects that use PostgreSQL such as OpenFTS and PostG

I imagine nobody is happier to hear this that PostgreSQL. Their popularity is about to skyrocket as countless OSS projects look for alternatives to MySQL.

I develop Access databases for a living (among other things...), but:

$ sudo apt-get install postgres pgaccess
$ pgaccess

Full GUI goodness for creating your postgres database.

$ pg_dump my_guified_db > m_g_d.sql

Email sql script (which contains all reports, tables views, etc...)

The next person needs to import ("open") the database, like this
$ psql my_other_db < m_g_d.sql
$ pgaccess

And the next person is up and running with their GUI goodness.

Yes, I used the command-line there, because it's the easiest way to show how simple it is. There are GUIs to do the import, export, and program install too, but I couldn't put screenshots in here.

FWIW: Access doesn't come with most versions of Office today. (I have to specifically inform my clients to get Office Professional, not Office Small Business Edition or Office Standard, and then to do a custom install to get Access on the machine...) But, just as with postgres/pgaccess, all that only has to be done once...

Er, it's already done.

(Ok, so one still interface pg with SQL, but the other items on your list checks off)

While PostgreSQL usually doesn't seem to get decent press from O'Reilly, it practially dominated the database talks at OSCON. Just about every database event either included or featured PostgreSQL.

The things in the works for 8.1 and 8.2 are looking very interesting indeed. Besides 2-phase commit and bitmap indexes:

- Full multi-master replication with Slony 2 (Slony 1 is single-master)
- IN/OUT paramater declaration for more flexibility in functions (making PL/PgSQL even more like PL/SQL)
- Much more useable and flexible custom datatype creation. "Complex" dataypes may not seem too useful for standard business databases, but they have all sorts of applications in areas like mapping, engineering, scientific analysis, etc... (Not to mention which, you might even want to think in terms of mapping custom datatypes to classes in your applications.)
- Horizontal partitioning: this is a concept used in very large tables, where you might want different groups of rows from one table stored in different locations, such as different physical disks, SANs, etc... This sort of thing is actually already being done informally by leveraging PostgreSQL's table inheritance features and tablespaces, but in the future (8.2 or 8.3?) it should become a standard feature.

Speaking of which, how many people caught Josh Berkus and Joe Conway's talk on "Terabytes of Business Intelligence"? Very interesting insights on how to handle very large databases in PostgreSQL. For example, Joe Conway's project gathers statistics from industrial equipment around the world, receiving several GB a day of data on the central server, an 8-CPU XEON, storing the data on a SAN array via NFS mount configured for jumbo frames. To handle the super-large main table, he created a partitioning schema where there are 12 sub-tables, each holding the data for one month of the year, and then creating a main table via inheritance from these tables to present a unified relation of all this data. In some ways this may sound like a view from a UNION query, but the implementation has much better performance and maintenance implications.

All this means PostgreSQL is steadily gaining ground on the Big 3 database vendors, and in some ways surpassing them, as far as the quality of the implementation. Many of the distinctions now are in external areas, such as application servers and federated systems. (You can do either of these things in PostgreSQL, but there is no official standardized method)

We all know that the main DB vendors don't allow anyone to publish benchmarks without permission, so of course there are no easily accessible benchmarks between PostgreSQL and Oracle, for instance. But, in informal talks at OSCON, I found at least a couple companies who had done their own internal benchmarks and PostgreSQL came out ahead surprisingly often.