On Sun, Aug 02, 2009 at 01:42:13AM -0400, Alexy Khrabrov wrote:
> Well, my question, of course, is, how come all those differences might
> affect PG binary data so much -- portable design would try to minimize
> such effects, wouldn't it? Does it optimize for all of the above
> intentionally, is it a side-effect of its design, and/or is there a set
> of options for the build time which might minimize binary
> incompatibility? I'd like to understand exactly why and how we get
> binary incompatibility, and what exactly do we get for not having it,
> and can it be a choice. There's a lot of databases out there. e.g.
> Berkeley DB, where the backup is mv or ftp. Performance is allright,
> too. I wish I could configure some of my PG ones that way...
As long as you're only dealing with strings it's not a problem, but
when you start talking about integers or floating point there is no
"standard format". While it would theoretically be possible to make a
binary compatable version, the cost would be an extra conversion layer
for each and every column access in every table.
This is before you have even taken into acocunt the fact that different
CPUs have different alignment requirements for different types, so to
be portable you would have to take the worst case, which is just
wasting space on architectures which don't need it.
Finally you have effects like on 64-bit architectures you can pass a
64-bit value in a register, whereas on 32-bit architectures you may need
to allocate memory and pass a pointer.
Binary compatability takes work and costs performance and we prefer to
focus on other things.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.
