From: | Sean Chittenden <sean(at)chittenden(dot)org> |
---|---|
To: | Dror Matalon <dror(at)zapatec(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: go for a script! / ex: PostgreSQL vs. MySQL |
Date: | 2003-10-09 18:11:12 |
Message-ID: | 20031009181112.GA71907@perrin.nxad.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> Yeah, I had similar thought to Oliver's and suspected that this
> would be the answer. Also, while it's not too hard to do this for a
> single platform, it gets complecated once you start looking at
> different ones.
>
> Josh, let me know when you're ready to do this. I'll try to help,
> although my perl's kind of rusty. Also, can you even assume perl for
> a postgres install? Does Solaris, for instance come with perl?
Um, why not wait until the C version of initdb is committed, then
steak out a section that'll allow us to submit patches to have initdb
autotune to our hearts content? There's a tad bit of precedence with
having shared buffer's automatically set in initdb, why not continue
with it? I know under FreeBSD initdb will have some #ifdef's to wrap
around the syscall sysctl() to get info about kernel bits. Talking
about how to expand handle this gracefully for a gazillion different
platforms might be a more useful discussion at this point because I'm
sure people from their native OS will be able to contrib the necessary
patches to extract info from their OS so that initdb can make useful
decisions. Or, lastly, does anyone think that this should be in a
different, external program? -sc
--
Sean Chittenden
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2003-10-09 18:12:30 | Re: Sun performance - Major discovery! |
Previous Message | Bruce Momjian | 2003-10-09 18:10:44 | Re: Sun performance - Major discovery! |