From: Carlos Moreno <moreno_pg@mochima.com>
To: pgsql-performance@postgresql.org
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning
Date: Thu, 03 May 2007 18:42:12 -0400
Message-ID: <463A6544.4090605@mochima.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0705031419130.26172@asgard.lang.hm>
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>
>> 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
--
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: moreno_pg@mochima.com
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning
In-Reply-To: <463A6544.4090605@mochima.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox