Hi Maciej,
Am 02.12.2009 um 15:35 schrieb Maciej (Matchek) Blizinski:
On Mon, Nov 30, 2009 at 10:27 AM, Dagobert Michelsen
<[email protected]> wrote:
Hi Maciej,
On build8s the tests pass just fine. Is it something that buildfarm
admins can fix?
Yes. I need to turn up SHMMAX on build8x and reboot. As I plan to
migrate
that
on the VMware farm I can just install the new one for you to test.
Please
allow
me some more time to finish it.
Sure. Please let me know when it's done. I'll build the Intel
architecture packages then.
Meanwhile, I'd like to continue the 32/64 bit PostgreSQL discussion.
My intuition is that application should run the native architecture
binaries, unless there's a reason to do otherwise. Dago wrote, that
it makes sense to do run 64-bit binaries (where possible) by default,
when:
(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 agree with the second point, because it's phrased too
strongly. 64-bit will not always be advantageous, because you can
find such data and such criteria that 32-bit binary will do better.
I understand that for many applications there's no advantage in
running in 64-bit width, and therefore the main policy is "use 32 bit
only unless there are reasons to use 64-bit". In the case of a
database engine, there is one general reason to use 64-bit width:
databases tend to be big and run on big machines, using way more than
just 2GB of RAM. Defaulting to 32-bit is like setting up a trap.
I understand that the two main arguments against using 64-bit by
default where possible are:
- it consumes more memory
- it potentially runs slower
I've got a Netra T1125 2X 440MHZ to experiment with. I've run pgbench
using sparcv8 and sparcv9 binaries.
sparcv8
tps = 22.976848 (including connections establishing)
tps = 23.070799 (excluding connections establishing)
sparcv9:
tps = 25.318832 (including connections establishing)
tps = 25.481666 (excluding connections establishing)
I also know that Dago didn't want to use isaexec, because somebody
might want to copy raw data directories between 32- and 64-bit
architecture machines. I agree that it might happen, but as far as my
database experience goes, messing with raw data directories is
generally asking for trouble. The way to get the data to or out of a
database is via database dumps, which are architecture independent.
If somebody wants replication, they should use slony.
We could have a postinstall script which would detect and set the
architecture, but isn't it what isaexec does anyway?
Yes, but on every invocation. You can execute the postinstall selecting
32/64 bit with isaexec for optimal selection, but the selection should
be static and not be changed between invocations of the database.
One more thing: using isaexec doesn't take the choice away. The user
can still set the path to the exact binary and run 32 or 64-bit
version specifically, if they want to.
To sum up: I maintain that it's best to:
1. Use native architecture width by default
2. Give the user the choice if they have a preference this or the
other way
isaexec does both those things.
There's another way of doing it: Force the user to choose the
architecture before they can run PostgreSQL at all. I think it would
be a user-repellent policy. It's so much nicer when the package runs
out of the box:
pkgutil -y -i postgresql
sudo -u postgres createuser joe
createdb joe
psql
The negative impact of the database not working out of the box would
in my opinion by greater than the positive impact of being always
conscious about whether it's possible to copy the data files between
machines with different bit width architectures.
If people want to, I can draw another table with pros and cons.
For me you can just default to 64 bit as almost all systems support it
and as you said the advantage is there.
Best regards
-- Dago
_______________________________________________
maintainers mailing list
[email protected]
https://lists.opencsw.org/mailman/listinfo/maintainers
