Re: [GENERAL] New FAQ item

> actually, via refint, you do have foreign keys.

True, but people just want Foreign Key to work from within their SQL
commands.

>
> > [SNIP]
> > In comparison to MySQL or leaner database systems, we are
> > slower because we have transaction overhead. We are built for
> > flexibility and features, not speed, though we continue to
> > improve performance through profiling and source code analysis.
>
> id rephrase this to include 'inserts/updates' -- 6.5 is comparable to
> mysql for selects, given the proper indexes.

Done.

> id also stress that postgres supports (fully?) SQL92, triggers,
> transactions, subselects, views, etc; these features are currently
> unimplemented in mysql and msql ( does anyone still _use_ msql? 3hours
> for a 2 table join was just a big nono ).

Done.

> or maybe instead of comparing to mysql/msql, compare pgsql to oracle,
> sybase, informix, et al. much cleaner comparison there, seeing
> that mysql/msql dont support triggers, transactions, etc.

Yes, I agree we compare much more easily to the big guys, but that
information may not be getting out as much as it should, so we have to
include the obvious MySQL comparison.

New text attached. Copy on the web site too.

---------------------------------------------------------------------------

1.14) How does PostgreSQL compare to other DBMS's?

There are several ways of measuring software: features, performance,
reliability, support, and price.

Features
PostgreSQL has most features present in large commercial
DBMS's, like transactions, subselects, triggers, views, and
sophisticated locking. We have some features they don't have,
like user-defined types, inheritance, rules, and multi-version
concurrency control to reduce lock contention. We don't have
foreign key referential integrity or outer joins, but are
working on them for our next release.

Performance
PostgreSQL runs in two modes. Normal fsync mode flushes every
completed transaction to disk, guaranteeing that if the OS
crashes or looses power in the next few seconds, all your data
is safely stored on disk. In this mode, we are slower than most
commercial databases, partly because few of them do such
conservative flushing to disk in their default modes. In
no-fsync mode, we are usually faster than commercial databases,
though in this mode, an OS crash could cause data corruption.
We are working to provide an intermediate mode that suffers
from less performance overhead than full fsync mode, and will
allow data integrity within 30 seconds of an OS crash. The mode
is select-able by the database administrator.

In comparison to MySQL or leaner database systems, we are
slower on inserts/updates because we have transaction overhead.
Of course, MySQL doesn't have any of the features mentioned in
the Features section above. We are built for flexibility and
features, not speed, though we continue to improve performance
through profiling and source code analysis.

Reliability
We realize that a DBMS must be reliable, or it is worthless. We
strive to release well-tested, stable code that has a minimum
of bugs. Each release has at least one month of beta testing,
and our release history shows that we can provide stable, solid
releases that are ready for production use. We believe we
compare favorably to other database software in this area.

Support
Our mailing list provides a large group of developers and users
to help resolve any problems encountered. While we can not
guarantee a fix, commercial DBMS's don't always supply a fix
either. Direct access to developers, the user community,
manuals, and the source code often make PostgreSQL support
superior to other DBMS's. There is commercial per-incident
support available for those who need it. (See support FAQ
item.)

Price
We are free for all use, both commercial and non-commercial.
You can add our code to your product with no limitations,
except those outlined in our BSD-style license stated above.