Re: PostgreSQL a slow DB?

Hi All

I started using PostgreSQL\Postgis in January. Lately I have been
reading on the internet many rumblings about PostgreSQL being slower than
MySQL/SQLLite etc etc. Comparisons made were routine inserts , updates,
and deletes. Is any of this true? If so,are there methods to speed
things up? I used the Explain Analyze command on portgesSQL it seemed
fast although I have not run any other DB's.
I know when comparison tests are performed they can be tilted on these
internet sites. But I see so many people declaring PostgreSQL to be the
slowest I am thinking where there is smoke there's fire.

Elwood Cordery
Rockwell Collins
Contract Software Engineer
319-295-8248

On Thursday 23 March 2006 11:14 am, ebcorder(at)rockwellcollins(dot)com saith:
> Hi All
>
> I started using PostgreSQL\Postgis in January. Lately I have been
> reading on the internet many rumblings about PostgreSQL being slower than
> MySQL/SQLLite etc etc. Comparisons made were routine inserts , updates,
> and deletes. Is any of this true? If so,are there methods to speed
> things up? I used the Explain Analyze command on portgesSQL it seemed
> fast although I have not run any other DB's.
> I know when comparison tests are performed they can be tilted on these
> internet sites. But I see so many people declaring PostgreSQL to be the
> slowest I am thinking where there is smoke there's fire.
>
>
> Elwood Cordery
> Rockwell Collins
> Contract Software Engineer
> 319-295-8248
>

There is a thread regarding MySql versus PostgreSQL on the general list. Take
a look at that.

> Hi All
>
> I started using PostgreSQL\Postgis in January.
> Lately I have been
> reading on the internet many rumblings about
> PostgreSQL being slower than
> MySQL/SQLLite etc etc. Comparisons made were
> routine inserts , updates,
> and deletes. Is any of this true? If so,are
> there methods to speed
> things up? I used the Explain Analyze command on
> portgesSQL it seemed
> fast although I have not run any other DB's.
> I know when comparison tests are performed they can
> be tilted on these
> internet sites. But I see so many people declaring
> PostgreSQL to be the
> slowest I am thinking where there is smoke there's
> fire.
>
>
> Elwood Cordery
> Rockwell Collins
> Contract Software Engineer
> 319-295-8248

you've been using PGSQL for almost 3 months now. do
*you* think it is slow for your application and
hardware?

for my intranet application, pgsql is blazing fast -
at least with several hundred rows and complex
selects. the data will grow over time, however, it
isn't like i have 2 million rows, but i do have some
reasonably advanced selects (or so it seems to me!).

mysql has a reputation for being slightly faster for
simple tasks. i'm not sure how true that is now that
they have stapled on a lot of advanced db features
that postgresql had integrated from the beginning.

did you see that sony online entertainment chose
postgresql for their gaming site?

http://www.enterprisedb.com/news_events/press_releases/03_20_06b.do

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

ebcorder(at)rockwellcollins(dot)com wrote:
>
> Hi All
>
> I started using PostgreSQL\Postgis in January. Lately I have been
> reading on the internet many rumblings about PostgreSQL being slower than
> MySQL/SQLLite etc etc. Comparisons made were routine inserts , updates,
> and deletes. Is any of this true? If so,are there methods to speed
> things up? I used the Explain Analyze command on portgesSQL it seemed
> fast although I have not run any other DB's.
> I know when comparison tests are performed they can be tilted on these
> internet sites. But I see so many people declaring PostgreSQL to be the
> slowest I am thinking where there is smoke there's fire.

Lots of people still think Elvis is alive. :-)

--
Bruce Momjian http://candle.pha.pa.us

+ If your life is a hard drive, Christ can be your backup. +

Mr. Momjian,
Congratulations on the new position at EnterpriseDB.

On 4/8/06, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
>
> ebcorder(at)rockwellcollins(dot)com wrote:
> >
> > Hi All
> >
> > I started using PostgreSQL\Postgis in January. Lately I have been
> > reading on the internet many rumblings about PostgreSQL being slower
> than
> > MySQL/SQLLite etc etc. Comparisons made were routine inserts , updates,
> > and deletes. Is any of this true? If so,are there methods to speed
> > things up? I used the Explain Analyze command on portgesSQL it seemed
> > fast although I have not run any other DB's.
> > I know when comparison tests are performed they can be tilted on these
> > internet sites. But I see so many people declaring PostgreSQL to be the
> > slowest I am thinking where there is smoke there's fire.
>
> Lots of people still think Elvis is alive. :-)
>
> --
> Bruce Momjian http://candle.pha.pa.us
>
> + If your life is a hard drive, Christ can be your backup. +
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

MySQL 5 is quickly catching up. Maybe someone can elaborate on the
advantages of Postgres over MySQL 5?

thanks,
-Sid

On 4/9/06, Mike <1100100(at)gmail(dot)com> wrote:
>
> Mr. Momjian,
> Congratulations on the new position at EnterpriseDB.
>
>
> On 4/8/06, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us > wrote:
> >
> > ebcorder(at)rockwellcollins(dot)com wrote:
> > >
> > > Hi All
> > >
> > > I started using PostgreSQL\Postgis in January. Lately I have been
> > > reading on the internet many rumblings about PostgreSQL being slower
> > than
> > > MySQL/SQLLite etc etc. Comparisons made were routine inserts ,
> > updates,
> > > and deletes. Is any of this true? If so,are there methods to speed
> > > things up? I used the Explain Analyze command on portgesSQL it
> > seemed
> > > fast although I have not run any other DB's.
> > > I know when comparison tests are performed they can be tilted on these
> >
> > > internet sites. But I see so many people declaring PostgreSQL to be
> > the
> > > slowest I am thinking where there is smoke there's fire.
> >
> > Lots of people still think Elvis is alive. :-)
> >
> > --
> > Bruce Momjian http://candle.pha.pa.us
> >
> > + If your life is a hard drive, Christ can be your backup. +
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
> >
>
>

--
Sid Murthy

That doesn't really help anwser the question...
The developers in our office (and myself) are also under the impression that
PG is a very slow database.
Also when you look thru the "performance" newsgroup, it seems to me that
what people are saying is true.

So instead of being a jerk to those of us who are a "novice" to PG, how
about giving some concrete answers to these performance questions.

> ebcorder(at)rockwellcollins(dot)com wrote:
>>
>> I know when comparison tests are performed they can be tilted on these
>> internet sites. But I see so many people declaring PostgreSQL to be the
>> slowest I am thinking where there is smoke there's fire.

"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote in message
news:200604090338(dot)k393c8G09848(at)candle(dot)pha(dot)pa(dot)us(dot)(dot)(dot)
>
> Lots of people still think Elvis is alive. :-)
>
> --
> Bruce Momjian http://candle.pha.pa.us
>

> did you see that sony online entertainment chose
> postgresql for their gaming site?
>
> http://www.enterprisedb.com/news_events/press_releases/03_20_06b.do
>

No, they chose EnterpriseDB (EDB), not Postgresql (PG).
Even thou EDB used PG as it's start, it is not PG.
EDB also claims to be 50% faster than PG!!

This is almost like Sybase taking credit for any deals that SQLServer gets.

> MySQL 5 is quickly catching up. Maybe someone can
> elaborate on the
> advantages of Postgres over MySQL 5?
>
> thanks,
> -Sid

i can't speak for everyone, but for me...

1. the license is bsd.
2. the license is bsd.
3. the license is bsd.
4. mysql didn't have foreign keys when i started.
5. mysql has more bugs to deal with.
6. the higher end features were designed in / built in
pgsql from the beginning - not tacked on aftre the
fact. think integrated vs hacked.
7. mysql has no significant feature advantage over
pgsql (many argue pgsql's features are significantly
better), but has license, corporate (oracle) and bug
liabilities.
8. the pgsql mailing list rocks! ;-) there are very
helpful folks here. this may be true of mysql mailing
lists, too. i don't know.

if you *know* the license issue will never be a
problem, and i doubt anyone really does (who can
predict the future?), and you already know mysql, it
may make sense to stay put with mysql vs learning
something entirely new.

however, if i were starting from scratch, i'd learn
pgsql (no buyer's remorse here - this db is great).
if i were worried about the license, i'd learn pgsql
and stop worrying. if i were worried about oracle's
influence on mysql, i'd learn pgsql and stop worrying.
if i wanted to improve my data integrity, i'd switch
to postgresql (bugs can chomp away at data).

this isn't to say that mysql is a bad db. since it is
so popular, it definitely fulfills the needs of many
people.

i'm sure i'd do pretty decent with it, too, if i had
to.

but i'm a happy customer here - and happy customers
stay put. actually, i'm more than happy. i'm
astounded that something like this exists under a
license like bsd. astounded.

hth

oe1

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

On Monday 10 April 2006 02:00 pm, operationsengineer1(at)yahoo(dot)com saith:
<snip>
>
> but i'm a happy customer here - and happy customers
> stay put. actually, i'm more than happy. i'm
> astounded that something like this exists under a
> license like bsd. astounded.
>

That makes two of us. We're getting ready to roll out a Logistics package
converted from a comerical DB to PostgreSQL. We love it. Period.

>> but i'm a happy customer here - and happy customers
>> stay put. actually, i'm more than happy. i'm
>> astounded that something like this exists under a
>> license like bsd. astounded.
>>
>
> That makes two of us. We're getting ready to roll out a Logistics package
> converted from a comerical DB to PostgreSQL. We love it. Period.

3... switzerland's largest cinema website moved from sql server to
postgresql two months ago. lost some comfort (automated backups, jobs) but
gained lot of performance, stability... and last but not least, budget! ;-)

- thomas

This thread touches upon your question regarding Mysql vs. Postgresql.

http://archives.postgresql.org/pgsql-general/2006-03/msg01004.php

Also from what I've read on the PG-Lists in regard to Postgres' speed, Postgresql default conf
parameters are conservatively set for cross-platform stability. ( I believe stability was the
operative word but I am not 100% sure.) It was then up to the administrator to optimize the conf
parameters to work most efficiently with their specific hardware thus producing significant
increases in server speed.

In beyond this, some of the threads indicate that additional speed increases are obtained by
selecting / arranging server hardware to fully utilize the strengths that PostgreSQL offers.

Also, in defense for the performance list. Many on the treads relating to performance problems
boil down to poor maintenance of the database. I.E. Vacuuming and Clustering. Also, many of the
other threads relate to administrators inquiries about the optimal setting for their conf files.
Lastly, the remaining threads discuss improving performance by altering SQL syntax. Very few
threads (if any) are resolved with the conclusion that Postgres is slow.

I hope this help in your evaluation.

Regards,

Richard

--- Sid Murthy <sid(dot)murthy(at)gmail(dot)com> wrote:

> MySQL 5 is quickly catching up. Maybe someone can elaborate on the
> advantages of Postgres over MySQL 5?
>
> thanks,
> -Sid
>
> On 4/9/06, Mike <1100100(at)gmail(dot)com> wrote:
> >
> > Mr. Momjian,
> > Congratulations on the new position at EnterpriseDB.
> >
> >
> > On 4/8/06, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us > wrote:
> > >
> > > ebcorder(at)rockwellcollins(dot)com wrote:
> > > >
> > > > Hi All
> > > >
> > > > I started using PostgreSQL\Postgis in January. Lately I have been
> > > > reading on the internet many rumblings about PostgreSQL being slower
> > > than
> > > > MySQL/SQLLite etc etc. Comparisons made were routine inserts ,
> > > updates,
> > > > and deletes. Is any of this true? If so,are there methods to speed
> > > > things up? I used the Explain Analyze command on portgesSQL it
> > > seemed
> > > > fast although I have not run any other DB's.
> > > > I know when comparison tests are performed they can be tilted on these
> > >
> > > > internet sites. But I see so many people declaring PostgreSQL to be
> > > the
> > > > slowest I am thinking where there is smoke there's fire.
> > >
> > > Lots of people still think Elvis is alive. :-)
> > >
> > > --
> > > Bruce Momjian http://candle.pha.pa.us
> > >
> > > + If your life is a hard drive, Christ can be your backup. +
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 2: Don't 'kill -9' the postmaster
> > >
> >
> >
>
>
> --
> Sid Murthy
>

> >> but i'm a happy customer here - and happy
> customers
> >> stay put. actually, i'm more than happy. i'm
> >> astounded that something like this exists under a
> >> license like bsd. astounded.
> >>
> >
> > That makes two of us. We're getting ready to roll
> out a Logistics package
> > converted from a comerical DB to PostgreSQL. We
> love it. Period.
>
> 3... switzerland's largest cinema website moved from
> sql server to
> postgresql two months ago. lost some comfort
> (automated backups, jobs) but
> gained lot of performance, stability... and last but
> not least, budget! ;-)

Thomas, can't pgsql backups be autmoated via cron
jobs? i think it is a bit more complex than point and
click, but once you know how, it isn't and issue
anymore.

speaking of knowing how... i'll be asking just this
question in the future. ;-)

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

> That doesn't really help anwser the question...
> The developers in our office (and myself) are also
> under the impression that
> PG is a very slow database.
> Also when you look thru the "performance" newsgroup,
> it seems to me that
> what people are saying is true.
>
> So instead of being a jerk to those of us who are a
> "novice" to PG, how
> about giving some concrete answers to these
> performance questions.
>
>
> > ebcorder(at)rockwellcollins(dot)com wrote:
> >>
> >> I know when comparison tests are performed they
> can be tilted on these
> >> internet sites. But I see so many people
> declaring PostgreSQL to be the
> >> slowest I am thinking where there is smoke
> there's fire.
>
> "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote in
> message
> news:200604090338(dot)k393c8G09848(at)candle(dot)pha(dot)pa(dot)us(dot)(dot)(dot)
> >
> > Lots of people still think Elvis is alive. :-)
> >
> > --
> > Bruce Momjian http://candle.pha.pa.us
> >

Relaxin... interesting name given your response.

i have found pgsql to be extremely fast on our
intranet production system (near instantaneous).
however, it currently doesn't have a lot of data - so
i'm not sure if it is a good gauge.

as for chatter, it is just that - chatter. would you
trust a debian fan to accurately describe gentoo? or
visa versa?

how about a microsoft sales rep and linux? it would be
very naive to think an accurate and fair assessment
would be given, no?

my guess is that you are tuned into a bunch of mysql
or mssql sites (oracle is alledgedly the slowest db of
them all). as for enterprise db's marketing... we
both know they take the absolute slowest postgresql
can be (ie, set pgsql to be as slow as possible) and
then they compare themselves to it in a test that
absolutely gives them the best possible advantage.

if they didn't, the marketing department would be
fired.

that's marketing. tune up pgsql and don't let
enterprise db manipulate the test to their absolute
best favor and i doubt the difference is noticable.
it surely is not 50% faster.

if you want a site that runs on postgresql, try
sesamestreet.org.

they use postgresql.

http://www.sesameworkshop.org/

no, not market hyped enterprise db and their fattest
marketing hype number they could spin.

postgresql is the db.

ps - it is silly to call a properly configured
postgresql db a slow db (slow defined in a rational
way) under acceptable loads for this db. typically,
only zealots with agendas do that kind of stuff.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

>> 3... switzerland's largest cinema website moved from
>> sql server to
>> postgresql two months ago. lost some comfort
>> (automated backups, jobs) but
>> gained lot of performance, stability... and last but
>> not least, budget! ;-)
>
> Thomas, can't pgsql backups be autmoated via cron
> jobs? i think it is a bit more complex than point and
> click, but once you know how, it isn't and issue
> anymore.
>
> speaking of knowing how... i'll be asking just this
> question in the future. ;-)

of course it can. but it's not as comfortable as through an internal db
scheduling job. in mssql, you also could schedule just about anything...
like reindex, data integrity checks, etc.. all of these can be handled
through a cron job or a windows task as well, but its kinda an external
process compared to the way it is done in mssql.

i saw internal schedule jobs already being on the wishlist for future pgsql
versions :-)

cheers,
thomas

On April 9, 2006 07:02 am, "Relaxin" <me(at)yourhouse(dot)com> wrote:
> That doesn't really help anwser the question...
> The developers in our office (and myself) are also under the impression
> that PG is a very slow database.
> Also when you look thru the "performance" newsgroup, it seems to me that
> what people are saying is true.

Like every database, PostgreSQL has some operations which are slower than
others. Some of these are things that developers, having experienced MySQL
in a development environment, might find to be much slower than MySQL. In
particular, UPDATEs and COUNT(*) are very slow compared to MySQL on MyISAM
tables. People also constantly run into problems from not VACUUMing their
tables (setup autovacuum first-thing), and by not tuning their installation
to their system (the default configuration is very conservative).

In practice, if setup and maintained correctly and and while used by
multiple users, PostgreSQL is actually quite fast, and it consistently gets
faster every release. 6.5 was a dog. Since 7.0, it's been quite usable,
and the 8.0 and 8.1 releases are awesome. People who looked at PostgreSQL
8 or 9 years ago and wrote it off as slow don't know what they're missing.

In addition, it has a lof of very nice features that other free products
lack, and it is incredibly good about protecting the integrity and
correctness of your data (something that MySQL is famously bad at, and the
reason many users of other databases hold MySQL in such disdain).

I think if you try both products, under any kind of concurrent read/write
load, especially if you use MySQL in a non-default manner that actually
guarantees safe data (ie. with InnoDB or at least by turning fsync on),
you will find that PostgreSQL compares quite favourably speed-wise, while
at the same time being just a much nicer product to work with.

This is of course just my opinion. I invite you to try the product before
dismissing it based on what some other people have to say.

--
Alan

> i have found pgsql to be extremely fast on our
> intranet production system (near instantaneous).
> however, it currently doesn't have a lot of data - so
> i'm not sure if it is a good gauge.
>
> as for chatter, it is just that - chatter. would you
> trust a debian fan to accurately describe gentoo? or
> visa versa?

You make a very good point. Also there are many people in the Postgresql community that are very
interested letting PostgreSQL shine in comparisons between Postgres and other RDBMS.

I thought the link aptly illustrates that point.

http://archives.postgresql.org/pgsql-performance/2006-03/msg00485.php

Regards,

Richard

hi all

me(at)alternize(dot)com schrieb:
>>> but i'm a happy customer here - and happy customers
>>> stay put. actually, i'm more than happy. i'm
>>> astounded that something like this exists under a
>>> license like bsd. astounded.
>> That makes two of us. We're getting ready to roll out a Logistics package
>> converted from a comerical DB to PostgreSQL. We love it. Period.
>
>
> 3... switzerland's largest cinema website moved from sql server to
> postgresql two months ago. lost some comfort (automated backups, jobs
are you sure? we do the backup automatically (cron-job/ windows:
at-job) in this way, you have something like (scheduled) local packages.
> but gained lot of performance, stability... and last but not least,
> budget! ;-)
>
> - thomas
we are still using a mssql-server. we also use a pgsql-server on linux
for 3 small to medium applications, and we are _very_ happy with
postgres (on linux) in terms of performance, stability, and
manageability. in fact, we are planning right now to port one
application from mssql to postgres.

chris

sid(dot)murthy(at)gmail(dot)com ("Sid Murthy") writes:
> MySQL 5 is quickly catching up. Maybe someone can elaborate on the
> advantages of Postgres over MySQL 5?

The trouble with the "catching up" that MySQL has been doing is that
it is coming at the "benefit" of adding checkbox points [Features X,
Y, and Z now supported] at the cost that they are adding "gotchas"
<http://sql-info.de/mysql/gotchas.html> much faster than they are
eliminating them.

For instance, it's "wonderful" that they have added built-in
replication. At least, it's wonderful until you see the pretty
enormous set of caveats.
<http://dev.mysql.com/doc/refman/5.0/en/replication-features.html>
<http://dev.mysql.com/doc/refman/5.0/en/stored-procedure-logging.html>

Not all of those issues have yet entered the Gotchas list...

The trouble, in effect, is that they are "slapping on" new features as
opposed to "designing in" new features.

Generally speaking, if you look at PostgreSQL features that get added,
they are "designed in," and can be expect to work pretty well
anywhere. The same does not appear to be true when features are added
to MySQL.
--
(format nil "~S(at)~S" "cbbrowne" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/rdbms.html
Rules of the Evil Overlord #161. "I will occasionally vary my daily
routine and not live my life in a rut. For example, I will not always
take a swig of wine or ring a giant gong before finishing off my
enemy." <http://www.eviloverlord.com/>

Sheesh, the day after I unsubscribe due to lack of time I get this
email. Before you take some anecdotal words on the subject, think about
it. MySQL is fine for running some databases for websites and webapps.
SQLLite is also. But they do not scale the way PostgreSQL does. Are
these people comparing some measly little Wordpress database running
MySQL against a huge Postgres database with a ton of data and a ton of
stored-proc functionality coded into it?

I would need to see apples-to-apples benchmarks done by comparing the
various database systems running the same or very similar databases.
And do it for small-size databases all the way up through large ones, to
see how well they all perform as you increase the scale. Oh, and you
may have to dumb down the benchmark schema used to account for all the
functionality that PostgreSQL has that don't exist in the others.

We once, at a customer's insistence, ported a fairly complex schema with
a lot of stored proc functionality from PostgreSQL to Oracle. Its was
based on managerial fiat, not from some technical reason. It was very
time consuming and difficult. There were just so many features that we
made use of that Oracle had no counterpart for, and we had to write a
lot of custom code to implement.

If you have a tiny database, with tiny requirements, and have to run on
old, slow equipment, then maybe it doesn't matter what database you use,
they'll all perform the same. But if you need to do real work, I'll
take PostgreSQL.

The only time I've heard of or experienced speed issues was in the days
of running Postgres on Windows via cygwin. And the culprit there was
cygwin, not Postgres. Cygwin is slow. Its not meant for that kind of
production use. Postgres would have to run on top of it and suffered
from cygwin's slowness. But these days Postgres runs native on
Windows. I don't have to run Postgres on Windows anymore, so I don't
know how the native Win32 Postgres performs, but with cygwin out of the
loop it should be fine.

Perhaps the many rumblings you heard were from people still dealing with
cygwin on Windows?

McC

Bruce Momjian wrote:
> ebcorder(at)rockwellcollins(dot)com wrote:
>
>> Hi All
>>
>> I started using PostgreSQL\Postgis in January. Lately I have been
>> reading on the internet many rumblings about PostgreSQL being slower than
>> MySQL/SQLLite etc etc. Comparisons made were routine inserts , updates,
>> and deletes. Is any of this true? If so,are there methods to speed
>> things up? I used the Explain Analyze command on portgesSQL it seemed
>> fast although I have not run any other DB's.
>> I know when comparison tests are performed they can be tilted on these
>> internet sites. But I see so many people declaring PostgreSQL to be the
>> slowest I am thinking where there is smoke there's fire.
>>
>
> Lots of people still think Elvis is alive. :-)
>
>

"Alan Hodgson" <ahodgson(at)simkin(dot)ca> wrote in message
news:200604101804(dot)03763(at)hal(dot)medialogik(dot)com(dot)(dot)(dot)
> On April 9, 2006 07:02 am, "Relaxin" <me(at)yourhouse(dot)com> wrote:
>
> I think if you try both products, under any kind of concurrent read/write
> load, especially if you use MySQL in a non-default manner that actually
> guarantees safe data (ie. with InnoDB or at least by turning fsync on),
> you will find that PostgreSQL compares quite favourably speed-wise, while
> at the same time being just a much nicer product to work with.
>
> This is of course just my opinion. I invite you to try the product before
> dismissing it based on what some other people have to say.
>

Thank you Alan for your response.

What I need ( and other novice) what are all of the parameters for and how
would you set them up properly, so that we can also see the performance
benefits of PG?

I need this information for PG for Windows...I'm sure others need it for
Linux.

Thanks

My point was that:

>> slowest I am thinking where there is smoke there's fire.

is not a valid method of analysis.

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

Relaxin wrote:
> That doesn't really help anwser the question...
> The developers in our office (and myself) are also under the impression that
> PG is a very slow database.
> Also when you look thru the "performance" newsgroup, it seems to me that
> what people are saying is true.
>
> So instead of being a jerk to those of us who are a "novice" to PG, how
> about giving some concrete answers to these performance questions.
>
>
> > ebcorder(at)rockwellcollins(dot)com wrote:
> >>
> >> I know when comparison tests are performed they can be tilted on these
> >> internet sites. But I see so many people declaring PostgreSQL to be the
> >> slowest I am thinking where there is smoke there's fire.
>
> "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote in message
> news:200604090338(dot)k393c8G09848(at)candle(dot)pha(dot)pa(dot)us(dot)(dot)(dot)
> >
> > Lots of people still think Elvis is alive. :-)
> >
> > --
> > Bruce Momjian http://candle.pha.pa.us
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote in message
news:200604131313(dot)k3DDD6Q05741(at)candle(dot)pha(dot)pa(dot)us(dot)(dot)(dot)
>
> My point was that:
>
> >> slowest I am thinking where there is smoke there's fire.
>
> is not a valid method of analysis.
>

It works for me...

Quoth "Relaxin" <me(at)yourhouse(dot)com>:
> "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote in message
> news:200604131313(dot)k3DDD6Q05741(at)candle(dot)pha(dot)pa(dot)us(dot)(dot)(dot)
>>
>> My point was that:
>>
>> >> slowest I am thinking where there is smoke there's fire.
>>
>> is not a valid method of analysis.
>
> It works for me...

Except when it doesn't work. It's a completely non-scientific method
of determining answers, and has *enormous* bias due to ignorance.

Traditionally, MySQL(tm) has had a lot of loosely-done, unanalyzed
"benchmarketing" done where the tests done are those that can be done
without any real design. MySQL(tm) probably still has some advantages in
performance when the usage patterns combine:
a) Single user access
b) A series of simple queries expected to access one or two tuples
c) Low system load
d) A pattern that discourages transaction usage

Any "designed in 15 minutes" sort of benchmark is quite likely to fit
into this.

"Let's go insert 20000 rows into a table, and then run 20000 queries
that each pull one of those rows, and see how long it takes."

It has been common for MySQL(tm) with MyISAM to win these sorts of
"contests" that are obviously biased to what it was designed to do
well, as a thin veneering of SQL on top of a B-Tree ISAM library.

Vary any of those assumptions, and the results change pretty
substantially.

-> MyISAM doesn't scale at all well with many concurrent updaters,
whereas PostgreSQL, for instance, handles that extremely well.
-> No transaction overhead goes along with no transactional integrity;
you can't expect consistent results to come back without your
application being very careful to never cross any of the
"semantic lines" that will make MySQL(tm) eat your data.
-> There's an interesting paucity of benchmarks involving the newer
"transactional storage engines" (and presumably there never will
be any, as they are now all owned by "no, you can't publish that
benchmark" Oracle). Indications are that the InnoDB engine
drops performance by a fair bit, particularly any time there is
need to roll back transactions...
-> Complex queries favor the systems with better query optimizers,
and PostgreSQL does Quite Well there. DB2 is probably the best
available, optimization-wise, but that's not surprising, as
their developers have been at it for about 30 years now.
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://linuxdatabases.info/info/slony.html
"MICROS~1: The People who Brought the Y2K Bug into Software Titling"
-- cbbrowne(at)hex(dot)net

> Except when it doesn't work. It's a completely non-scientific method
> of determining answers, and has *enormous* bias due to ignorance.
>

That has been my question all along...
Instead of "beating" people down when they (and others) have a concern,
rather it's real or not, you guy have to put real concrete information and
solutions out there to counter these misconceptions.

My co-workers and I believe that PG is slow.
A way of helping this is by providing a solution to configuring the database
to work the best for a person setup, or give them some general parameters to
look into.

The impression of PG being slow will not be solved by statements such as
"Some people believe Elvis is still alive."

> Traditionally, MySQL(tm) has had a lot of loosely-done, unanalyzed
> "benchmarketing" done where the tests done are those that can be done
> without any real design. MySQL(tm) probably still has some advantages in
> performance when the usage patterns combine:
> a) Single user access
> b) A series of simple queries expected to access one or two tuples
> c) Low system load
> d) A pattern that discourages transaction usage
>
> Any "designed in 15 minutes" sort of benchmark is quite likely to fit
> into this.
>
> "Let's go insert 20000 rows into a table, and then run 20000 queries
> that each pull one of those rows, and see how long it takes."
>
> It has been common for MySQL(tm) with MyISAM to win these sorts of
> "contests" that are obviously biased to what it was designed to do
> well, as a thin veneering of SQL on top of a B-Tree ISAM library.
>
> Vary any of those assumptions, and the results change pretty
> substantially.
>
> -> MyISAM doesn't scale at all well with many concurrent updaters,
> whereas PostgreSQL, for instance, handles that extremely well.
> -> No transaction overhead goes along with no transactional integrity;
> you can't expect consistent results to come back without your
> application being very careful to never cross any of the
> "semantic lines" that will make MySQL(tm) eat your data.
> -> There's an interesting paucity of benchmarks involving the newer
> "transactional storage engines" (and presumably there never will
> be any, as they are now all owned by "no, you can't publish that
> benchmark" Oracle). Indications are that the InnoDB engine
> drops performance by a fair bit, particularly any time there is
> need to roll back transactions...

I see and hear this kind of stuff all the time.
Every company has a boilerplate answer to why the competition is worse.

So how does a potential user figure out which is better...

More people know of MySQL and MySQL is assoicated with speed.
Rather it's real or not, it doesn't matter. MySQL has got mindshare.

PG is assoicated to slow, complex, hard to use and arrogant support.

Stop with the "My daddy can beat up your daddy" mentality and show us HOW to
setup
PG to be fast.
That why, we can ALSO be a voice to prove that PG is fast and not complex
and eventually disspell the notion that PG is a slow database.

Thanks

At 03:00 PM 4/14/06, Relaxin wrote:
>That has been my question all along...
>Instead of "beating" people down when they (and others) have a concern,
>rather it's real or not, you guy have to put real concrete information and
>solutions out there to counter these misconceptions.
>
>PG is assoicated to slow, complex, hard to use and arrogant support.
>
>Stop with the "My daddy can beat up your daddy" mentality and show us HOW to
>setup PG to be fast.
>That why, we can ALSO be a voice to prove that PG is fast and not complex
>and eventually disspell the notion that PG is a slow database.

We have to respond with concrete answers to your concerns that are not
real? Ha ha!

What if we don't care that there are misconceptions out there, because we
have done our own investigation and testing and pg came out the winner?

Complex? No, just drop in and use it - with a default install it's as easy
to use as mysql - in fact I've found it easier (I do use both all the
time). If you need complex features, you'll find them in pg - or you can
ignore them.

I would not say that support is arrogant, but it is very problem
focused. When a specific issue is presented, answers are provided (on any
of the various pg) lists. Vague questions get vague answers (as is to be
expected). I think the general consensus of the various email on this
topic hilight the fact that performance measurements are very much
dependant on design & config factors. So whether mysql or pgsql is faster
is a question only you can answer for your own database and usage
patterns. Published performance results are also "out-of-date" in less
than a year as new versions of each package are released.

Setup both mysql and pgsql on the same test box and populate with some of
your own data; if pg isn't faster than mysql in your situation, post your
schema, sql and results from "explain analyse". Somebody here will find a
way to make the query faster. If you want mysql to "win" the race, take
your question to a mysql list and ask them how to make it faster on that
system.

At the end of the day, speed isn't everything. As other messages have
mentioned, for some installations, a database system can be made "fast
enough" on given hardware - at which point other features of the database
system become more important than speed. My database are not humongous;
queries run "fast enough" on consumer hardware - my users are not
complaining; I like many features of pgsql that mysql does not have (also
mentioned by others in this thread). I don't know of any mysql features
lacking in pgsql.

Christopher Browne wrote:

>Quoth "Relaxin" <me(at)yourhouse(dot)com>:
>
>
>>"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote in message
>>news:200604131313(dot)k3DDD6Q05741(at)candle(dot)pha(dot)pa(dot)us(dot)(dot)(dot)
>>
>>
>>>My point was that:
>>>
>>>
>>>
>>>>>slowest I am thinking where there is smoke there's fire.
>>>>>
>>>>>
>>>is not a valid method of analysis.
>>>
>>>
>>It works for me...
>>
>>
>
>Except when it doesn't work. It's a completely non-scientific method
>of determining answers, and has *enormous* bias due to ignorance.
>
>
Watching this thread leads me to believe that:
1) There may - or - may not be an existing MySql production database.
2) The developer(s) have not installed/tested PostgreSQL.
3) An internal discussion is taking place, with the desired goal being
to make an "either/or" decision, without actual comparison testing.

I would suggest that IF the production database is sufficiently
important AND the end goal is to make a choice based on performance,
then both dbs should be installed and compared using the desired
functionality. If after comparison testing, PG comes out on the short
end, then post specifics to this list and there are a fair # of users
that MAY be able to make suggestions that could substantially improve PG
performance for the specific usage.

If this dual level of testing is more work than desired, then the
desired production database is not sufficiently important and the
discussion is moot.

So the first step would seem to be answering the question, "Is the
project important enough to warrant comparison testing?" If it is, then
the project enables a "scientific method" of analysis and this group can
help (with sufficient facts) in the final decision-making process.

In short, "trust no one", instead, trust the methodology.

>Except when it doesn't work. It's a completely non-scientific method
>of determining answers, and has *enormous* bias due to ignorance.

I'm admitting my ignorance by posting in the "novice" group.

Where can I get answers on what those options can do for me, that you have
to pick when you install PG?

Also where can I get information on what all of the configuration options
are for and how they can help PG?

Christopher Browne <cbbrowne(at)acm(dot)org> writes:
> Traditionally, MySQL(tm) has had a lot of loosely-done, unanalyzed
> "benchmarketing" done where the tests done are those that can be done
> without any real design. MySQL(tm) probably still has some advantages in
> performance when the usage patterns combine:
> a) Single user access
> b) A series of simple queries expected to access one or two tuples
> c) Low system load
> d) A pattern that discourages transaction usage
> Any "designed in 15 minutes" sort of benchmark is quite likely to fit
> into this.

FWIW, the last time I tried Postgres on the "benchmark" test suite that
comes with MySQL, PG was about half the speed of MySQL overall. Now
MySQL AB have obviously spent a lot more than 15 minutes on mysql-bench,
but it answers the rest of Chris' description pretty well.

The other little problem with mysql-bench is that it's *by design*
biased to overweight things that MySQL is particularly fast at, and
underweight things it's not. I'm not certain the MySQL guys even
consciously recognize that, but think about how it works: practically
all of the tests involve repeating some-trivial-operation N number of
times. That would be fine, except they choose different numbers N for
different tests, apparently with the goal of making sure each test takes
about the same total time when run on MySQL. For example, let's assume
that query A takes 1 second and query B takes 10 seconds on MySQL, but
vice versa on Postgres. If these were in mysql-bench, the benchmark
would be set up to run A say 100 times and B 10 times, making each
component of the benchmark run for 100 sec on MySQL. Total score: 200
sec. PG comes along and runs A*100 in 1000 sec and B*10 in 10 sec, for
a total score of 1010 sec. Obviously PG sucks, right? No, it's the
methodology. And that doesn't even consider the fact that the benchmark
suite simply doesn't test anything you can't do at all in MySQL.

I think a lot of the "PG is slow" buzz you hear on the net is from
people who have been misled by mysql-bench and other poorly designed
benchmarks.

Now, if the actual use you intend to put the database to matches the
single-client, lots-of-very-simple-queries model, then by all means you
should take a hard look at MySQL. But if you've got concurrent clients
or complicated queries, you had better do your own benchmarking. BTW,
don't forget that when the MySQL fanboys say "we're fast AND we've got
transactions", they usually omit to mention "(but not at the same
time)". MySQL isn't really one database, it's three or four different
ones depending on which storage engine you use. And they've got
different feature sets and performance profiles. Be real wary about
extrapolating results with one storage engine to another one. (I'm
pretty sure that mysql-bench tests only MyISAM.)

regards, tom lane

Relaxin wrote:
> > Except when it doesn't work. It's a completely non-scientific method
> > of determining answers, and has *enormous* bias due to ignorance.
> >
>
> That has been my question all along...
> Instead of "beating" people down when they (and others) have a concern,
> rather it's real or not, you guy have to put real concrete information and
> solutions out there to counter these misconceptions.
>
> My co-workers and I believe that PG is slow.
> A way of helping this is by providing a solution to configuring the database
> to work the best for a person setup, or give them some general parameters to
> look into.
>
> The impression of PG being slow will not be solved by statements such as
> "Some people believe Elvis is still alive."

Let me tell you what I say at trade show booths when someone asks why
they should use PostgreSQL rather than MySQL:

"Oh, I think you should use MySQL. It has a nice cute name."

Of course, the questioner gets this strange look on their face, and
might ask another question, or just leave.

Of course, the question is similar to, "Convince me to date your
sister." It isn't a very reasonable question.

The bottom line is that we are community project, and we don't have any
reason to try to convince you to use or software or not. There is no
direct connection between your using our software and any benefit to us.
This is unlike MySQL and other commercial companies that have a very
real motivation to encourage you to use their software.

In fact, it is fact we have no _need_ to sell you on our software that
helps us provide superior solutions comared to commercially-produced
software.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I know this will pin the corny-meter, but ---
I feel such a large boulder of gratitude and appreciation for the users on
this list.
This thread has been incredibly educational for me.

I've never had enough time to learn and employ postgresql either at home or
at the workplace (a whole bunch priority things that I won't bore you with),
but I continue to subscribe and follow a few threads every week. I cannot
unsubscribe from this list. Every time I spend more than 10 minutes looking
into a thread or two, I go away more educated about *nix and open source
systems in general.

I thank you for giving me the opportunity to learn from your ideas, your
work, and your experience.

Mike

Bruce Momjian wrote:

>Relaxin wrote:
>
>
>>>Except when it doesn't work. It's a completely non-scientific method
>>>of determining answers, and has *enormous* bias due to ignorance.
>>>
>>>
>>>
>>That has been my question all along...
>>Instead of "beating" people down when they (and others) have a concern,
>>rather it's real or not, you guy have to put real concrete information and
>>solutions out there to counter these misconceptions.
>>
>>My co-workers and I believe that PG is slow.
>>A way of helping this is by providing a solution to configuring the database
>>to work the best for a person setup, or give them some general parameters to
>>look into.
>>
>>The impression of PG being slow will not be solved by statements such as
>>"Some people believe Elvis is still alive."
>>
>>
>
>Let me tell you what I say at trade show booths when someone asks why
>they should use PostgreSQL rather than MySQL:
>
> "Oh, I think you should use MySQL. It has a nice cute name."
>
>Of course, the questioner gets this strange look on their face, and
>might ask another question, or just leave.
>
>

That strange look is them thinking that the person they're talking to is
a jerk. Who in their right mind would think that a person working a
booth for a company would actually want you to use their product and
would be civil enough to provide information on why they should use your
product? The nerve of these people.

If anyone working for me gave a boneheaded response like that I would
fire them on the spot.

>Of course, the question is similar to, "Convince me to date your
>sister." It isn't a very reasonable question.
>
>The bottom line is that we are community project, and we don't have any
>reason to try to convince you to use or software or not. There is no
>direct connection between your using our software and any benefit to us.
>This is unlike MySQL and other commercial companies that have a very
>real motivation to encourage you to use their software.
>
>In fact, it is fact we have no _need_ to sell you on our software that
>helps us provide superior solutions comared to commercially-produced
>software.
>
Your need, or lack of need, to sell something has no bearing on whether
or not you should show basic courtesy when responding to questions about
a product you represent. Want a better and larger community? Don't be
a tool.

--
Brant Fitzsimmons
brant(at)bfcomputerconsulting(dot)com
-------------------------------------------------------------------
"Strange times are these in which we live when the old and the
young are taught falsehoods in the schools of learning. And the one
man that dares to tell the truth is called at once a lunatic and
a fool."
-Plato

Brant Fitzsimmons wrote:
> >Of course, the questioner gets this strange look on their face, and
> >might ask another question, or just leave.
> >
> >
>
> That strange look is them thinking that the person they're talking to is
> a jerk. Who in their right mind would think that a person working a
> booth for a company would actually want you to use their product and
> would be civil enough to provide information on why they should use your
> product? The nerve of these people.
>
> If anyone working for me gave a boneheaded response like that I would
> fire them on the spot.

We can't be fired, which is kind of my point.

> >Of course, the question is similar to, "Convince me to date your
> >sister." It isn't a very reasonable question.
> >
> >The bottom line is that we are community project, and we don't have any
> >reason to try to convince you to use or software or not. There is no
> >direct connection between your using our software and any benefit to us.
> >This is unlike MySQL and other commercial companies that have a very
> >real motivation to encourage you to use their software.
> >
> >In fact, it is fact we have no _need_ to sell you on our software that
> >helps us provide superior solutions comared to commercially-produced
> >software.
> >
> Your need, or lack of need, to sell something has no bearing on whether
> or not you should show basic courtesy when responding to questions about
> a product you represent. Want a better and larger community? Don't be
> a tool.

When you are in the booth long enough, you need some kind of
entertainment. Someone else usually jumps in and answers the question,
but that type of question can usually be answered only by asking the
questioner more questions.

Technically, though, I don't think it is our role as community members to
convince people to use our software, is it?

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

You may get all the documtention from the site, plus a good search in
google would help also.

You may want to take a look at:

http://www.postgresql.org/docs/ # this will provide you with the
official documentation.

read it ALL :)
-----------------------------------------------------------------

http://techdocs.postgresql.org/ # a pretty good set of comunity
tech doc, cases.

You will find good tips here.
-----------------------------------------------------------------

http://www.varlena.com/GeneralBits/Tidbits/annotated_conf_e.html

If you are brave enough, then visit the above url.

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

For a quick reply:

irc://irc.freenode.net , join #postgresql

Good people working there for free.

Tho, about this thread, you shall get a closer look yourself at all
the documentation, prior to asking the wolves >:} about the rocking
features of postgresql. That would make you smarter when asking, and
you will probably avoid a spammy thread.

Are you currently using mysql? If so, are you using InnoDB or the
default ISAM engine?
Are you aware of the Oracle move against MySQL? Do you fully
understand what MVCC provides? Would it be usefull in your case? Have
you checked http://bugs.mysql.com ? Do you know what Firebird is and
how does MySQL plans to replace InnoDB?

Are you enough sure about what rdbms fits your needs? Do you fully
understand what your current license means and provides? Read, it's
healthy, and it will provide you with knoweledge, which will probably
create good questions to sort, rather than which one is faster. :)

If you are still worried about how fast, quick, speedy, rapid
postgresql is, then take your own choice, measure it, do your own
benchmarks and return them to this comunity, we'll be happy to discuss
that.

Best wishes,
Guido
--
Guido Barosio
-----------------------
http://www.globant.com
guido(dot)barosio(at)globant(dot)com

On Mon, April 17, 2006 2:07 pm, Bruce Momjian said:
>
> Technically, though, I don't think it is our role as community members to
> convince people to use our software, is it?

No, but actively driving them away won't help either. Our role probably
*is* to convince them we are civilized people.

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------

Append:

Not the more up-to-date pages, but try also:

http://en.wikipedia.org/wiki/Postgresql
http://en.wikipedia.org/wiki/MySQL

Rgds,
g.-

On 4/17/06, Guido Barosio <gbarosio(at)gmail(dot)com> wrote:
> You may get all the documtention from the site, plus a good search in
> google would help also.
>
> You may want to take a look at:
>
> http://www.postgresql.org/docs/ # this will provide you with the
> official documentation.
>
> read it ALL :)
> -----------------------------------------------------------------
>
> http://techdocs.postgresql.org/ # a pretty good set of comunity
> tech doc, cases.
>
> You will find good tips here.
> -----------------------------------------------------------------
>
> http://www.varlena.com/GeneralBits/Tidbits/annotated_conf_e.html
>
> If you are brave enough, then visit the above url.
>
> -----------------------------------------------------------------
>
> For a quick reply:
>
> irc://irc.freenode.net , join #postgresql
>
> Good people working there for free.
>
>
> Tho, about this thread, you shall get a closer look yourself at all
> the documentation, prior to asking the wolves >:} about the rocking
> features of postgresql. That would make you smarter when asking, and
> you will probably avoid a spammy thread.
>
> Are you currently using mysql? If so, are you using InnoDB or the
> default ISAM engine?
> Are you aware of the Oracle move against MySQL? Do you fully
> understand what MVCC provides? Would it be usefull in your case? Have
> you checked http://bugs.mysql.com ? Do you know what Firebird is and
> how does MySQL plans to replace InnoDB?
>
> Are you enough sure about what rdbms fits your needs? Do you fully
> understand what your current license means and provides? Read, it's
> healthy, and it will provide you with knoweledge, which will probably
> create good questions to sort, rather than which one is faster. :)
>
> If you are still worried about how fast, quick, speedy, rapid
> postgresql is, then take your own choice, measure it, do your own
> benchmarks and return them to this comunity, we'll be happy to discuss
> that.
>
> Best wishes,
> Guido
> --
> Guido Barosio
> -----------------------
> http://www.globant.com
> guido(dot)barosio(at)globant(dot)com
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido(dot)barosio(at)globant(dot)com

On Monday 17 April 2006 17:39, Relaxin wrote:
> >Except when it doesn't work. It's a completely non-scientific method
> >of determining answers, and has *enormous* bias due to ignorance.
>
> I'm admitting my ignorance by posting in the "novice" group.
>
>
> Where can I get answers on what those options can do for me, that you have
> to pick when you install PG?
>
> Also where can I get information on what all of the configuration options
> are for and how they can help PG?
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

Hilou,

Taste and try before you buy.

Lotsa people talkin', few of them know ...

Have you actually installed and run this 'slow' (r)dbms ? On what hardware ?
OS(s) / distro(s) ? Locales ? Collates ? Etc. ? What are you planning to do ?

Read the docs and manuals. RTFM, I know ...

With my limited experience from RH 6.0 to FC.modern / such like, and coming
from an ancient background before desktop and all these mobile what-you-have
things, I must say communities like this / ours are the juice of the
industry. As opposed to proprietary systems and slow moving mammoths like,
you know. No names. I once had a 'fully operational' #%-system installed with
%#SQL-server and all. Yeah. Now I know.

What is slow ? Millisec-wise ? Local network ? Via internet ? Or is the bottle
neck actually the bottle neck you are holding ? Grab the bottle and drink it,
meanwhile, re-plan your query and output.

Just reading these lists has taught me more than I ever bargained for. I hope
I can some day give something back.

This kind of thread is getting no one no where. Yes, no, yesn't s/he ?

Hack before you whack.

And I encourage you to test Pg. Amongst other things in life.

--
Aarni Ruuhimäki
--------------
This is a bugfree broadcast to you
from **Kmail**
on **Fedora Core** linux system
--------------

Hi all,

Just in case this has not been covered in this thread, I will
point out that for some speed of operation is of no great interest
in selection of a database. The processes I run spend 90% of their
time in the application and data transfer, and 10% in the database.

Of course I endorse the comments that a lot of work and knowledge
is needed to get the best out of postgresql in terms of speed, but
for me it runs quickly enough using the defaults. If speed
becomes an issue I will ask the mailing list, but I suspect that
good database design is much more important.

Areas that may be of more interest than speed are: support;
documentation; table and tuple locking; data backup and restoration;
interface to perl; interface to ODBC; compliance with standards;
scalability. These are something a novice, by definition, cannot
evaluate.

I didn't spend a lot of time evaluating postgresql's features
against other DB's. I took the advice of someone I could trust.
Maybe if I was building a web app, or running mythTV, or storing
cooking recipies I might now be running a different db.

HTH

Richard A Lough

> Have you actually installed and run this 'slow' (r)dbms ? On what hardware
> ?
> OS(s) / distro(s) ? Locales ? Collates ? Etc. ? What are you planning to
> do ?
>
Yes, Windows XP and Windows2000 to replace Firebird and other databases.

> I must say communities like this / ours are the juice of the
> industry. As opposed to proprietary systems and slow moving mammoths like,
> you know. No names. I once had a 'fully operational' #%-system installed
> with
> %#SQL-server and all. Yeah. Now I know.
>
We are not a *nix shop and SQL-Server is working great for us (SQLServer
2000 that is)

> What is slow ? Millisec-wise ? Local network ? Via internet ? Or is the
> bottle
> neck actually the bottle neck you are holding ? Grab the bottle and drink
> it,
> meanwhile, re-plan your query and output.
>
In my test PG was faster than Firebird in a few queries, but most queries
were much slower.

These test were on version 7.* of PG.
And I also just recently found out that PG ran under something called
cgywin??
I guess it's some kind of emulator.

I'm sure that could make thinks run pretty slow.

Thanks

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Not the more up-to-date pages, but try also:
>
> http://en.wikipedia.org/wiki/Postgresql
> http://en.wikipedia.org/wiki/MySQL

What makes those not up to date? Myself and others actually go
to great lengths to make sure that they are very current.
If you have suggestions for the page, please send me an email,
use the talk page of those articles, or simply edit it yourself. :)

Thanks,
- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 200604172139
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFEREOOvJuQZxSWSsgRAvXnAJ9B6Bsjbc/eYfLCCMhtkWm5/qprjQCePj5K
aOmXenmn/nJmpK3T7ypu36s=
=uiKp
-----END PGP SIGNATURE-----

> > That why, we can ALSO be a voice to prove that PG
> is fast and not complex
> > and eventually disspell the notion that PG is a
> slow database.

the idea that postgresql is complex is rather ironic
since i really appreciated the simplicity of foreign
keys that mysql lacked at the time.

iow, i viewed postgresql as simpler in one "key" area,
pun intended.

as for complexity, this isn't a simple addition
calculator. it has features. with features comes
complexity. does pgsql have unnecessary complexity?

as a user fo this db for over 1.5 years, that thought
has never crossed my mind.

btw, did anyone go over to the mysql mailing list and
ask them if their db of choice is a "toy database?"
-lol-

why not go over to the fedora core mailing list and
tell them their distro is substandard because they
don't have apt.

i'd consider that approach trolling... and i also
believe we've been trolled here... even if out of
naivette.

postgresql is one darn fine database and it meets and
exceeds my needs - and i'm picky.

the license is hands down better than mysql. mysql
has to worry about oracle. as Tom pointed out, they
may have some advantages with speed, but only when
they don't use transactions (hint, postgrsql *always*
has that functionality). postgesql is less likely to
change your data w/o telling you.

is pgsql perfect? nope. the main gripe i heard last
time postgresql was mentioned on slashdot was that it
is a bit difficult (doable, but not easy) to backup
postgresql real time. a few folks said that was all
that was holding them up from switching to postgresql.
i've also heard folks call mysql a "toy database"
over on slashdot a few times. i don't believe this,
though, and have the sense to realize that mysql does
serve many people very well.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

hi

Relaxin schrieb:
>
>
> I see and hear this kind of stuff all the time.
> Every company has a boilerplate answer to why the competition is worse.
the manner of your replays lets me assume - well, never mind, that's not
my level of discussion.
>
> So how does a potential user figure out which is better...
as you have read, this depends on your circumstances. you _never_
specified what you are going to do with this database...
>
> More people know of MySQL and MySQL is assoicated with speed.
> Rather it's real or not, it doesn't matter. MySQL has got mindshare.
so does windows... again: not a bad software as well, depending on what
you want to do!
>
> PG is assoicated to slow,
we experience it as very fast
complex, hard to use
I don't regard me to be a genius, nevertheless had never any problems to
work with postgres. pgadmin has its hickups, but most of the time i'm
working on the console. you see again, it depends what you are doing
and how do you like to work
and arrogant support.
I always got fast and good answers in the forum. maybe what you
troubled was an echo of your own call? c'est le ton qui fait la musique,
as we like to say...
>
> Stop with the "My daddy can beat up your daddy" mentality and show us HOW to
> setup
> PG to be fast.
> That why, we can ALSO be a voice to prove that PG is fast and not complex
> and eventually disspell the notion that PG is a slow database.
there is no 'best' or 'worts' it always depends on the task. I admit, I
as well could have used a good list showing in which circumstances
which database performs best. The problem is, that such a list must be
written by a person with thorough knowledge of all compared databases.
>
> Thanks
cheers,
c
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
>