Thread: 64 Bit Compatibility
Jeff wrote: > *I* know what "64 bit compatibility" means, but I have been programming for > 20 years.. how many members of the press corps are going to know what that > means? and if someone doesn't know what it means, how likely are they to > look it up or ask someone that knows about these things? > as a test, I just asked a Cisco router guy if he knew what "64 bit > compatibility" means.. and the first question he asked was "in what > context"? I then explained that it was the context of "RDBMS software", and > he was *still* not sure what I was talking about, and didn't see any > benefit. Then let's ask ourselves: "What use is 64 bit compatibility?" Answer: "... 64 bit support means database processes can access more than 2GB of physical memory, which is vital for supporting large enterprise databases and data warehousing applications." The problem with "only 32 bits" is that you can't make use of >2GB of RAM on a system. (Well, on a 4GB IA-32 box, you could have PostgreSQL consume up to 2GB, and then see filesystem cacheing use the rest, but you still only have direct access to 2GB at a time...) This is the reason why Opteron, in particular, should be very exciting. It breaks the 2GB barrier without having to resort to really expensive "proprietary Unix" hardware. Something resembling my "quoted" bit should be added, as it gives people some idea as to what 64 bits "fixes." -- let name="cbbrowne" and tld="libertyrms.info" in String.concat "@" [name;tld];; <http://dev6.int.libertyrms.com/> Christopher Browne (416) 646 3304 x124 (land)
Folks, > > *I* know what "64 bit compatibility" means, but I have been > programming for > > 20 years.. how many members of the press corps are going to know what > that > > means? and if someone doesn't know what it means, how likely are they to > > look it up or ask someone that knows about these things? In one way, it's not important. "64 Bit Compatibility" is one of today's tech buzzwords, like "Web Services" or like "ready for the Enterprise" was 3 years ago. These terms and phrases too vague to be meaningful in and of themselves, but it's important to point out that you "have" them loudly and repeatedly lest you get classified as "legacy software" by the press ... and in the corporate executive boardroom, where VP decisions are often governed by buzzwords: Pointy-Haired Boss: We need to migrate to a SQL Server. Dilbert Thinks: (Is this something he really wants, or something he saw in a trade magazine?) Dilbert Asks: What color should that SQL Server be, boss? Pointy-Haired Boss: Blue. Dilbert: Right away, sir! Like "Web Services", "64 Bit Compatiblity" is nothing new; Java and Perl have been supporting "web services" for 5-6 years, and most Unix software has been compiled to Sparc or MIPS years ago. But the general trade press just discovered "64 Bit Compatibility" two years ago, so it's "cutting edge" to them. The real news worth reporting from us is that we have at least one proven and tested PostgreSQL version working on Opteron, and that PostgreSQL will compile on Opteron out of the tarball, including making some advantage of the extra memory space. Also that we've been compiled, tested, and running on several other 64-bit architectures, some for years. But we do need to use the phrase "64 Bit Compatible" or "64 Bit Optimized" or something similar. Reporters in the general trade press look for those kinds of buzz phrases. P.S. The Open Source press generally know better, but in a way they're not as important for us to reach, since they already know the value of PostgreSQL. -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus wrote:
> In one way, it's not important. "64 Bit Compatibility" is one of
> today's tech buzzwords, like "Web Services" or like "ready for the
> Enterprise" was years ago. These terms and phrases too vague to be
> meaningful in and of themselves, but it's important to point out
> that you "have" them loudly and repeatedly lest you get classified
> as "legacy software" by the press ... and in the corporate
> executive boardroom, where VP decisions are often governed by
> buzzwords:
The dichotomy is precisely why I suggested the wording I suggested.
"PostgreSQL support for 64 bit systems means database processes can
access more than 2GB of physical memory, which is vital for managing
large enterprise databases and data warehousing applications."
That combines the buzzword ("64 bit") with terse but real _reason for
usefulness_ that might conceivably give people a clue as to why "64
bits" is more than merely a buzzword.
> I'm reluctant to give up the mention of Oracle, becuase without it
> the quote lacks all punch. However, we don't have to say "faster
> than" if that's going to be a trigger for them. What about:
> "If you tried PostgreSQL before, and went with a commercial database
> like Oracle or DB2 instead, it's time to re-evaluate," says
> Rod. "PostgreSQL's tremendously improved performance and
> ever-expanding feature set make PostgreSQL competitive with even the
> highest-end database systems."
Let me suggest new words to put in Rod's mouth...
"If you tried PostgreSQL before [a thought: mention a time frame,
like 'last year'], and performance comparisons led you to choose
databases like DB/2 or Oracle, it is time to re-evaluate.
PostgreSQL's performance has improved tremendously [time frame?
'over the last two years'?] and this, along with its ever-expanding
feature set makes it competitive with even the highest end database
systems."
Putting in timeframes gives the message that if someone evaluated some
older version, then their conclusions then are invalid now. And it
does so without saying "You're wrong!"
Of course, if Rod wants to say other words, the words certainly are
his to generate :-).
--
"cbbrowne","@","libertyrms.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
Christopher Browne wrote: > Then let's ask ourselves: "What use is 64 bit compatibility?" > > Answer: > > "... 64 bit support means database processes can access more than 2GB of > physical memory, which is vital for supporting large enterprise > databases and data warehousing applications." > > The problem with "only 32 bits" is that you can't make use of >2GB of > RAM on a system. (Well, on a 4GB IA-32 box, you could have PostgreSQL > consume up to 2GB, and then see filesystem cacheing use the rest, but > you still only have direct access to 2GB at a time...) I belive 4gig is the limit for 32 bits. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Wed, Jul 23, 2003 at 03:19:27PM -0400, Christopher Browne wrote: [..snipped..] > Let me suggest new words to put in Rod's mouth... > > "If you tried PostgreSQL before [a thought: mention a time frame, > like 'last year'], and performance comparisons led you to choose > databases like DB/2 or Oracle, it is time to re-evaluate. > PostgreSQL's performance has improved tremendously [time frame? > 'over the last two years'?] and this, along with its ever-expanding > feature set makes it competitive with even the highest end database > systems." [..snipped..] > I agree :) however, I object to the phrase "ever-expanding feature set".. there are certain closed source vendors (and even mysql) that suffer from this sort of thing, and I wouldn't want pg to be associated in a reporters mind that way. it reminds me too much of "creaping featurism". :) certainly on the hackers list, "new features" are basically at the bottom of the list of priorities-- they make changes to improve stability and performance *first* before adding new features, and I think this should come across clearly in the press release. regards, J -- || Jeff - http://zoidtechnologies.com/ || GNUPG Fingerprint: A607 0F19 7C75 1305 67E4 BDFF 26BD 606E 3517 2A42