Message-ID: <463A6544.4090605@mochima.com>
Date: Thu, 03 May 2007 18:42:12 -0400
From: Carlos Moreno <moreno_pg@mochima.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning
References: 
 <OFC96167D5.6BB63AC2-ON652572C9.003B5263-652572C9.003E4142@lntinfotech.com>
	<200705010923.47951.josh@agliodbs.com>
	<Pine.GSO.4.64.0705012154380.24215@westnet.com>
	<200705031221.56226.josh@agliodbs.com>
	<Pine.LNX.4.64.0705031314310.26172@asgard.lang.hm>
	<463A4ED6.2040907@mochima.com>
	<Pine.LNX.4.64.0705031419130.26172@asgard.lang.hm>
In-Reply-To: <Pine.LNX.4.64.0705031419130.26172@asgard.lang.hm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


>> been just being naive) --- I can't remember the exact name, but I 
>> remember
>> using (on some Linux flavor) an API call that fills a struct with 
>> data on the
>> resource usage for the process, including CPU time;  I assume measured
>> with precision  (that is, immune to issues of other applications running
>> simultaneously, or other random events causing the measurement to be
>> polluted by random noise).
>
> since what we are looking for here is a reasonable first 
> approximation, not perfection I don't think we should worry much about 
> pollution of the value.

Well, it's not as much worrying as it is choosing the better among two 
equally
difficult options --- what I mean is that obtaining the *real* resource 
usage as
reported by the kernel is, from what I remember, equally hard as it is 
obtaining
the time with milli- or micro-seconds resolution.

So, why not choosing this option?  (in fact, if we wanted to do it "the 
scripted
way", I guess we could still use "time test_cpuspeed_loop" and read the 
report
by the command time, specifying CPU time and system calls time.

>> As for 32/64 bit --- doesn't PG already know that information?  I mean,
>> ./configure does gather that information --- does it not?
>
> we're not talking about comiling PG, we're talking about getting sane 
> defaults for a pre-compiled binary. if it's a 32 bit binary assume a 
> 32 bit cpu, if it's a 64 bit binary assume a 64 bit cpu (all hardcoded 
> into the binary at compile time)

Right --- I was thinking that configure, which as I understand, 
generates the
Makefiles to compile applications including initdb, could plug those values
as compile-time constants, so that initdb (or a hypothetical additional 
utility
that would do what we're discussing in this thread) already has them.  
Anyway,
yes, that would go for the binaries as well --- we're pretty much saying 
the
same thing  :-)

Carlos
--