Date: Thu, 9 Oct 2003 11:11:12 -0700
From: Sean Chittenden <sean@chittenden.org>
To: Dror Matalon <dror@zapatec.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: go for a script! / ex:  PostgreSQL vs. MySQL
Message-ID: <20031009181112.GA71907@perrin.nxad.com>
References: <B7397E6AC70AB1418180FA3480B9365556A69A@deun2kex01.realgarant.de>
	<200310090956.11356.josh@agliodbs.com>
	<20031009171715.GR2979@rlx11.zapatec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031009171715.GR2979@rlx11.zapatec.com>
User-Agent: Mutt/1.5.4i

> 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