Re: Migrating from 32 to 64 bit
От | Chris Browne |
---|---|
Тема | Re: Migrating from 32 to 64 bit |
Дата | |
Msg-id | 60r6iddmhj.fsf@dba2.int.libertyrms.com обсуждение исходный текст |
Ответ на | Migrating from 32 to 64 bit (Laurent CARON <lcaron@lncsa.com>) |
Ответы |
Re: Migrating from 32 to 64 bit
|
Список | pgsql-admin |
montaseri@gmail.com ("Medi Montaseri") writes: > But theoretically speaking, 32 or 64-bit ness of the application (ie the postmaster server) should not influence the datatypes 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" "@" "linuxdatabases.info") http://www3.sympatico.ca/cbbrowne/x.html "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
В списке pgsql-admin по дате отправления: