Re: Server recommendations

Ron Johnson wrote:
> On Mon, 2003-10-06 at 01:43, Shridhar Daithankar wrote:

>>The best performance is by running 32 bit applications on 64 bit kernel/hardware 
>>, according to a migration guide by HP. The reasoning is using space optimally
> Does HP have any AMD64 servers?

No. But while migrating from PA1.1 to PA2.0, they have had that pain..:-) And I 
just went thr. opteron optimization guide from a link you provided. Basically 
same stuff HP was pitching.

And I also configured a system on laclinux.com, just for curiosity. 2x 
1.8GHz/4GB/36GBx2 10K RPM SCSI/Adaptec 29320 for $4800/- is damn cheap a system. 
HP does not even start below $5K for 64 bit systems.

>>Imagine, if every long in pg is 8byte that would be waste most of the times. 
>>However given a native 8 byte integer/float is available, there is no reason to 
>>use a 8 byte data type unless required.
>From what I've read, longs are still 32-bit; it's only pointers 
> that have upped to 64-bit.

I thought under 64 bits short==2 bytes, int==4 bytes and long==8 bytes. i.e. 
this is another architecture/word length where int != long in size.

>>Its about exploiting wide and fast bus of a 64bit machine in a most optimal 
>>fashion. I think except for kernel and glibc, nothing else requires 64 bit in 
>>general unless application insists on doing it's own caching.
> In PG's case, if the app uses BIGINT a lot, then 64-bit PG should
> be more efficient.

Possibly. Source code availability has a great advantage here. Compile the way 
you want.

But still, as long as PG in itself does not use 8 byte data types exclusively, I 
would like it to be a 32 bit app. A bigint is 8 byte on a 64 bit machine, 
whether or not the app. is 32 bit.

> Besides, in 64-bit mode, the compilers get to use 2x as many GP
> registers, which should increase performance.

Well, if a 32 bit app. is optimised for opteron, compiler will use those 
registers anyway..:-)  At least on HP, such trick can be done. IMO thats very 
handy..

  Shridhar