Re: PostgreSQL on 64 bit Linux

On Mon, Aug 21, 2006 at 10:46:56AM -0400, mark(at)mark(dot)mielke(dot)cc wrote:
> Compilers are getting smarter, but having code profiled, and hand tuned
> for 32-bits does not automatically get compiled with a 64-bit compiler,
> to code that has been profile, and hand tuned for 64-bit.

I don't see any evidence that anyone has any kind of hand-tuning, not
for 32-bit, not for 64-bit. That's compiler's job really.

That's said, if you want to go hand-tuning, go for the low-hanging
fruit first: using likely()/unlikely() in often used code paths
(heap_get_attr for example), find the parts of the code that could
benefit from strict-aliasing, etc.

In general we avoid architechture specific code because the cost of
maintainence outweighs the benefits.

> For re-architecture, the first thing that came to mind was Datum
> increasing in size. Copy by value instead of allocating a pointer,
> and passing the pointer. The pointer will be 64-bits, so Datum
> could support 64-bits as well. Tom caught this, but he did point
> out what I missed. This would only benefit data types that are
> 64-bits in length, which are still likely uncommon (most people
> would use serial, not bigserial).

A Datum must be 64-bit on a 64-bit arch, how else is it going to hold
the pointer for a pass-by-ref value?

On the whole, PostgreSQL is still in the phase where we're trying to
find the best algorithms. When that's done (if ever), we can start
worrying about processor optimisations...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.