Brad Nicholson wrote:
>Actually, I think the biggest barrier to winning over this crowd is
>performance out of the box. MySQL just sort of "works" with the default
>settings, and is quite fast. The default Postgres install, well, if you
>don't tune the parameters, analyze your data, ect, the performance will
>be poor compared to MySQL.
>
>I was chatting with a developer the other day who uses MySQL, and he
>explained how he chose MySQL over Postgres. He loaded a fairly large
>data set into both, did some querying on it, and MySQL was way faster.
>I'm sure he didn't tune the conf file, or analyze the data, or some
>combination of the things you need to do.
>
>
>
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?
Brian