Re: Postgres v MySQL 5.0

From: usleepless(at)gmail(dot)com
To: "Brian Hurt" <bhurt(at)janestcapital(dot)com>
Cc: "Brad Nicholson" <bnichols(at)ca(dot)afilias(dot)info>, "Lukas Kahwe Smith" <smith(at)pooteeweet(dot)org>, "Leif B(dot) Kristensen" <leif(at)solumslekt(dot)org>, pgsql-advocacy(at)postgresql(dot)org
Subject: Re: Postgres v MySQL 5.0
Date: 2006-11-10 20:31:45
Message-ID: c39ec84c0611101231r19edae7aj4ff8203565f7215e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy

Hi All,

On 11/10/06, Brian Hurt <bhurt(at)janestcapital(dot)com> wrote:
> The problem with this is that there is no "one size fits all"
> configuration I can think of. Using 4G of memory on a machine with 8G
> of memory and the machine is dedicated to postgres is maybe about right,
> if not underutilizing the machine. Using 4G of memory on a machine with
> 256M of memory which is mainly doing other things is bad.
>
> What might not be a bad idea is a configuration generator- a simple
> program that you can give small amount of information to (how much
> memory to use, how many concurrent connections, etc) and produces a
> reasonable configuration file. This wouldn't necessarily be an optimal
> configuration file, and real admins would probably still want to hand
> edit their configuration file. For example, I would have it just
> generate more or less acceptable values for autovacuuming. This would
> be newbie oriented program- newbies don't know anything about vacuuming,
> let alone autovacuuming.
>
> I don't think this would be that hard to write. Thoughts?

i agree. lots of times postgresql is perceived as slow, because of
out-of-the-box configuration. most importantly, the memory
configuration.

perhaps a "make tune" or "make tune 50%" or "make tune 75%".

and it should be mentioned in the README, along with the make-instructions.

there is also another funny thing, about an article mentioned before:
http://tweakers.net/reviews/649/7

this is a dutch slashdot-alike site, which runs on mysql. the article
is about a back-to-back test between pgsql-mysql on opteron and
ultrasparc hardware. very thorough and well tuned.

they clearly show that postgresql scales much better.

the funny thing is: they don't consider switching to postgresql
themselves, even though they suffered a slashdotting a couple of
months back. i can't imagine they never had corrupted tables. would it
be worthwhile to have a postgresql-advocacy officer to contact them?

regards,

usleep

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Chris Browne 2006-11-10 20:53:56 Re: Postgres v MySQL 5.0
Previous Message Brad Nicholson 2006-11-10 20:05:20 Re: Postgres v MySQL 5.0