Re: Postgres v MySQL 5.0
От | usleepless@gmail.com |
---|---|
Тема | Re: Postgres v MySQL 5.0 |
Дата | |
Msg-id | c39ec84c0611101231r19edae7aj4ff8203565f7215e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Postgres v MySQL 5.0 (Brian Hurt <bhurt@janestcapital.com>) |
Ответы |
Re: Postgres v MySQL 5.0
|
Список | pgsql-advocacy |
Hi All, On 11/10/06, Brian Hurt <bhurt@janestcapital.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
В списке pgsql-advocacy по дате отправления: