[csw-maintainers] Building postgresql-8.4.1

Dagobert Michelsen dam at opencsw.org
Fri Nov 20 15:56:41 CET 2009


Hi Maciej,

Am 19.11.2009 um 10:26 schrieb Maciej (Matchek) Blizinski:
> On Wed, Nov 18, 2009 at 1:10 PM, Dagobert Michelsen  
> <dam at opencsw.org> wrote:
>> You assume that using 64 bit is always better than using 32 bit.
>
> That's too strong a statement. Let's put it this way: I assume it's
> not significantly worse.  But let's stop guessing and look at data.
> Do we have any numbers on it?  What's the difference in memory
> footprint between 32 and 64-bit versions?
>
>> This
>> is not the case. If you need more than 2 GB of RAM or have large
>> databases you are right.
>
> Basically, if somebody's database is growing, we're making sure that
> it's already grown big when they realize they need to switch to the
> 64-bit version.

The biggest concern for me is that the decision if 32 or 64 bit is
used is triggered from the state of the calling OS. That means if
the outer conditions from the OS change the database will change.
I admit that this will most of the time not make problems, but I
don't like the idea that moving to another host invalidates my
db structure. Defining 32/64 statically on installation and
even defaulting to 64 bit would IMHO be much better than isaexec
here.

>> But if the database is not that big you are
>> better off using 32 bit. IMHO it is good to automatically make the
>> 32/64 bit decision under the following circumstances:
>>
>> (1) using the proper width is mandatory (e.g. /dev/kmem access)
>> (2) using 64 bit always has an advantage
>> (3) there is difference in output between 32/64 bit
>>
>> I don't see that any of the above applies in the case of postgres.
>
> So why are we building everything else with isaexec?  For instance,
> why do we want cups to be 64-bit enabled?

We don't. As Phil explained, the libs should be available in 64 bit
everytime to allow compiling apps in 64 bit that need the libraries.
There is no need for an isaexec 64 bit print system.


Best regards

   -- Dago



More information about the maintainers mailing list