Skip site navigation (1) Skip section navigation (2)

Re: Migrating from 32 to 64 bit

From: "Medi Montaseri" <montaseri(at)gmail(dot)com>
To: "Chris Browne" <cbbrowne(at)acm(dot)org>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Migrating from 32 to 64 bit
Date: 2007-11-26 18:52:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-general
I agree with you practical points....I qualified my comments by
saying....theoretically speaking....


On Nov 26, 2007 8:01 AM, Chris Browne <cbbrowne(at)acm(dot)org> wrote:

> montaseri(at)gmail(dot)com ("Medi Montaseri") writes:
> > But theoretically speaking, 32 or 64-bit ness of the application (ie the
> postmaster server) should not influence the data types offered by a
> particular DB
> > version. That is the semantics of data types and cpu-arch (register
> width, big endian, little endian, sparc, mips, x86), etc ) offered by a
> particular DB
> > version should be orthogonal.
> > A practical example is when I first begin my business on a Mac, then I
> move the database to a Sun and then on to a mainframe....
> That's well and fine, but the point is that when those (reasonably
> generic!) data types get compiled into code for a particular platform,
> with particular endianness and word size, how it is optimal to
> represent them will vary based on the characteristics of the platform.
> As a result, not only do you need different executable binaries each
> platform, but you also need different binary database structures on
> each platform.
> A conceptually mitigating factor should be that by the time you get
> around to changing platforms, there will likely be a Newer, Better,
> Major PostgreSQL version available.  So you should be considering
> doing a migration from "old, slower, inferior version on the inferior
> platform" to the "better, stronger, faster version on the superior
> platform."  With THAT context, the need to run initdb is further
> "given."
> --
> output = ("cbbrowne" "@" "")
> "Have  you noticed   that,  when we were   young,  we were   told that
> `everybody else   is doing  it' was   a  really  stupid reason  to  do
> something,  but now it's the standard  reason for picking a particular
> software package?" -- Barry Gehm
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match

In response to

pgsql-admin by date

Next:From: José Roberto Motta GarciaDate: 2007-11-26 18:58:23
Subject: Re: Restoring wrong accents
Previous:From: Chris BrowneDate: 2007-11-26 16:01:44
Subject: Re: Migrating from 32 to 64 bit

pgsql-general by date

Next:From: Glyn AstillDate: 2007-11-26 18:57:19
Subject: Re: replication in Postgres
Previous:From: Joshua D. DrakeDate: 2007-11-26 18:48:11
Subject: Re: Primary Key

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group