Re: Postgres v MySQL 5.0
От | Brian Hurt |
---|---|
Тема | Re: Postgres v MySQL 5.0 |
Дата | |
Msg-id | 4554DA4F.1070107@janestcapital.com обсуждение исходный текст |
Ответ на | Re: Postgres v MySQL 5.0 (Brad Nicholson <bnichols@ca.afilias.info>) |
Ответы |
Re: Postgres v MySQL 5.0
Re: Postgres v MySQL 5.0 |
Список | pgsql-advocacy |
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
В списке pgsql-advocacy по дате отправления: