On Sat, May 31, 2003 at 02:09:45PM -0700, Fred Moyer wrote:
> I don't think you're out of touch - I think the people I'm trying to
> convince are. The crux of the problem I am dealing with is putting forth
> a robust argument for scaling PostgreSQL with 64 bit machines for
> increasing database sizes - Opteron was a natural choice because it is an
> inexpensive 64-bit machine. The MySQL argument was put forth by
> non-technical people who are have not thoroughly evaluated the differences
> between the two and have been swayed by marketing arguments.
>
> I guess what I am looking for here are real-world scenarios where
> PostgreSQL has been scaled using 64-bit. I as the technical person know
> the performance and scalability differences between running large datasets
> on 64 bit versus 32 bit machines and can put forth technical reasons for
> scaling Postgres as such - real world examples of it would validate my
> arguments.
You're mixing some theories. Because a machine is 64 bits doesn't mean
is just runs faster then 32 bits. Go figure why userland apps are
almost only 32 bits, even when running on 64 bits hardware. The
debian-sparc mailinglists has some good threads about. Also lkml had
some about increasing the size of the counter for the time from 32 to
64 bits and the impact.
Also 32 or 64 bits, it doesn't really matter to the max size of the
database and I must say Postgresql has a real nice way of fixing that
as far I have seen. And I don't really see this as an issue.
The only real pro about 64 bits is that the registers are bigger, but
then some processors just have more registers. So don't see 64 bits as
the holy grail for all the problems you have. And if you want to go 64
bits, go for a processor that is 64 bits for many years and has earned
his stars and strips IMHO.
--
Hans
