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
