The problem is that people often benchmark the so called vanilla
installation of PostgreSQL.
I understand why the PostgreSQL team has decided to have an overly
conservative default conf file. But no matter what the reason is or
who's to blame that a tester has not tuned PostgreSQL configuration, the
word is being spread that PostgreSQL is featurerich but _slow_. The
ongoing discussion currently in performance list is just one example. I
have seen it announce more than once: "we did not do any configuration
tuning on the test systems". Take
http://www.hwaci.com/sw/sqlite/speed.html as another example.
"The PostgreSQL and MySQL servers used were as delivered by default on
RedHat 7.2. (PostgreSQL version 7.1.3 and MySQL version 3.23.41.) No
effort was made to tune these engines. Note in particular the the
default MySQL configuration on RedHat 7.2 does not support transactions."
I remember a discussion in the general list about having multiple
default conf files to choose from. Ala low-end, average and high-end
installations. A tool to read some system information and dynamically
generating a proper configuration file was also mentioned.
The other issue that a lot of new PostgreSQL users seem to have is the
VACUUM ANALYZE. They just don't know about it. Perhaps some more active
ones will read the documentation or ask for help in email lists. But a
lot of them are surely leaving things and thinking of PostgreSQL as a
slow system. Remember they too spread the word of their experience.
I'm not an expert of PostgreSQL by any means I have just been reading
PostgreSQL email lists for only about a month or so. So I believe I have
read that there is a auto-vacuum being worked on? In my opinion this
should be included in the main installation by default. This is just the
kind of job that a machine should do...when a big portion of data has
changed do VACUUM ANALYCE automagically.
Is these improvements actually being implemented and how far are they?
The technical side of these problems is not for this list of course.
However the "side-effects" (reputation of being slow) of these problems
direclty relate to advocacy and PostgreSQL popularity. Maybe these
problems are already worked on or maybe I'm over exaggerating the
situation but I do believe solving these issues would only benefit
PostgreSQL.
Just my 2 c
Kaarel
