Thread: 7.4 Press Release -- Draft #4
The PostgreSQL Global Development Group is pleased to announce the
availability of version 7.4 of the PostgreSQL Relational Database
Management System (RDBMS). This major release represents the work
of our world wide network of over 100 developers and contributors over
the last 9 months, building on the unparalleled success of PostgreSQL 7.3.
Significant advances in PostgreSQL version 7.4 include:
- A complete redesign of error logging and reporting, providing
developers with an SQL99 compliant mechanism for debugging and
troubleshooting, providing users real time suggestions on how to avoid
error conditions in their applications.
- Improvements in subquery handling by the planner resulting in up to 400%
speed increases in some complex queries.
- The implementation of an SQL99 compliant Information Schema,
providing developers with database, type, object, and
configuration information in a standards compliant way.
- Now supports Statement level triggers, enabling developers and
users to define and customize behavior of the database when data is
stored and manipulated.
- Read only transactions, bringing a greater level of security to web and
enterprise applications by protecting data from modification.
- Optional explicit join rewriting by the query planner, easing the
transition of existing applications and queries running on Sybase and MS
SQL Server.
- Takes full advantage of large (>4GB) memory configurations on
numerous 64 bit platforms including AMD Opteron, HP/Compaq Alpha,
Sun UltraSPARC, MIPS, PA-RISC, and RS6000*
Other improvements include:
- Performance improvements for data warehousing
- Enhanced implementation of functional indexes
- Addition of polymorphic function arguments and return types
- Significant enhancements to array data types
- Completely overhauled and simplified documentation
- Improved vacuum process to manage indexes for high availability databases
- An auto-vacuum feature to help simplify database maintenance
- Updated multi-byte regular expression package for international users
- New wire protocol (version 3) increases the speed of data transfers
- Now supports both row level and statement level triggers
- A new ranked preference system for the TSearch full text indexing module.
As well as many other features and improvements.
"If you tried PostgreSQL before, and went with a commercial database like
Oracle or DB2 instead, it's time to re-evaluate," says Rod Taylor of Inquent
Technologies. "PostgreSQL's performance has improved tremendously over the
last two years and this, along with its enterprise level feature set, make
PostgreSQL competitive with even the highest-end database systems."
Source for this release is available at:
http://www.postgresql.org/mirrors-ftp.html
More information on PostgreSQL is available in ten languages on the
PostgreSQL Advocacy website:
http://advocacy.postgresql.org/
A complete list of changes in PostgreSQL version 7.4 can be found in the
HISTORY file included with the release, or available on the web at:
[http://www.postgresql.org/docs/release/740.html]
About PostgreSQL:
With more than 16 years of development by hundreds of the world's
most generous and brilliant minds from the open source community,
PostgreSQL is the world's most advanced open source database. With its
long time support of an enterprise level feature set including
transactions, stored procedures, triggers, and subqueries, PostgreSQL is
being used by many of today's most demanding businesses and government
agencies.
Corporations such as BASF, Red Hat, Afilias Limited (supporting the
technical back end of the .org and .info domains), Cisco, Chrysler, and
3Com rely on PostgreSQL's rock solid performance record and open
development process. PostgreSQL is available under a BSD License for
both commercial and non-commercial use.
To find out more about PostgreSQL or to download it, please visit:
http://www.postgresql.org/
---
issues/thoughts:
statement level triggers probably should be reworded/explained, perhaps
dropped to a one-liner
need to confirm the url for press releases (guess this means submitting the
code to cvs, anyone else want to dig up the old release notes and create
patches?)
new companies...
we need to start thinking about the order if the items mentioned above.
I'll be out of town till monday afternoon and not sure what kind of net access
I'll have. I suspect this can stew for a few days, but if I seem
unresponsive that's why.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Thu, 24 Jul 2003, Robert Treat wrote: > The PostgreSQL Global Development Group is pleased to announce the > availability of version 7.4 of the PostgreSQL Relational Database > Management System (RDBMS). This major release represents the work > of our world wide network of over 100 developers and contributors over > the last 9 months, building on the unparalleled success of PostgreSQL 7.3. > > Significant advances in PostgreSQL version 7.4 include: > > - A complete redesign of error logging and reporting, providing > developers with an SQL99 compliant mechanism for debugging and > troubleshooting, providing users real time suggestions on how to avoid > error conditions in their applications. > > - Improvements in subquery handling by the planner resulting in up to 400% > speed increases in some complex queries. > > - The implementation of an SQL99 compliant Information Schema, > providing developers with database, type, object, and > configuration information in a standards compliant way. > > - Now supports Statement level triggers, enabling developers and > users to define and customize behavior of the database when data is > stored and manipulated. Remove "Now supports", since it doesn't follow from 'version 7.4 include...'. > > - Read only transactions, bringing a greater level of security to web and > enterprise applications by protecting data from modification. > > - Optional explicit join rewriting by the query planner, easing the > transition of existing applications and queries running on Sybase and MS > SQL Server. > > - Takes full advantage of large (>4GB) memory configurations on > numerous 64 bit platforms including AMD Opteron, HP/Compaq Alpha, > Sun UltraSPARC, MIPS, PA-RISC, and RS6000* >4GB -> 'greater than 4 GB' > > Other improvements include: > - Performance improvements for data warehousing > - Enhanced implementation of functional indexes > - Addition of polymorphic function arguments and return types > - Significant enhancements to array data types > - Completely overhauled and simplified documentation > - Improved vacuum process to manage indexes for high availability databases > - An auto-vacuum feature to help simplify database maintenance > - Updated multi-byte regular expression package for international users > - New wire protocol (version 3) increases the speed of data transfers > - Now supports both row level and statement level triggers > - A new ranked preference system for the TSearch full text indexing module. > > As well as many other features and improvements. > > "If you tried PostgreSQL before, and went with a commercial database like > Oracle or DB2 instead, it's time to re-evaluate," says Rod Taylor of Inquent > Technologies. "PostgreSQL's performance has improved tremendously over the > last two years and this, along with its enterprise level feature set, make > PostgreSQL competitive with even the highest-end database systems." Some more quotes would be great. Bruce, Tom, Peter, anyone? Its looking good but. g
Gavin Sherry wrote: <snip> > Some more quotes would be great. Bruce, Tom, Peter, anyone? How about Andrew Sullivan, from Afilias? > Its looking good but. Agreed. It's already pretty decent. As a thought, is it worth mentioning that there'll be a "commercial grade" proper Open Source PostgreSQL replication systemavailable simultaneous to the 7.4 release? It's one of those things that is often asked about in higher-end installations, so letting people know in the pressrelease (widest possible audience) makes sense. Regards and best wishes, Justin Clift > g > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend
On Thu, Jul 24, 2003 at 02:23:07PM +0800, Justin Clift wrote:
> Gavin Sherry wrote:
> <snip>
> > Some more quotes would be great. Bruce, Tom, Peter, anyone?
>
> How about Andrew Sullivan, from Afilias?
Just for the record, I am _never_ allowed to speak for Afilias.
There's a whole communications department that handles that, and I'm
am nowise competent to stay "on message".
But I've forwarded something prepared by the communications folks.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On 24 Jul 2003 at 0:36, Robert Treat wrote: > - Takes full advantage of large (>4GB) memory configurations on > numerous 64 bit platforms including AMD Opteron, HP/Compaq Alpha, > Sun UltraSPARC, MIPS, PA-RISC, and RS6000* Itanium is missing. Surely nobody uses postgresql on itanium? Can we have a postgresql user registration system to solve problem of references once for all? Bye Shridhar -- untold wealth, n.: What you left out on April 15th.
On Thu, 2003-07-24 at 02:23, Justin Clift wrote:
> As a thought, is it worth mentioning that there'll be a "commercial grade" proper Open Source PostgreSQL replication
systemavailable simultaneous to the 7.4
> release? It's one of those things that is often asked about in higher-end installations, so letting people know in
thepress release (widest possible audience)
> makes sense.
>
I'd rather spin it off as its own press release...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
I'm Afilias' Communications Manager and try to keep up with the discussion on the list for areas where it is appropriate for us to help out. If anyone ever has any questions for us regarding press/marketing please feel free to direct them my way. Difference between me and Andrew is I can "speak" for Afilias ... after appropriate approvals of course ;) Heather -- Heather D. Carle Communications Manager Afilias Tel: +1.215.706.5700 x114 Fax: +1.215.706.5701 E-mail: hcarle@afilias.info http://www.afilias.info <http://www.afilias.info> -----Original Message----- From: pgsql-advocacy-owner@postgresql.org [mailto:pgsql-advocacy-owner@postgresql.org]On Behalf Of Andrew Sullivan Sent: Thursday, July 24, 2003 8:24 AM To: pgsql-advocacy@postgresql.org Subject: Re: [pgsql-advocacy] 7.4 Press Release -- Draft #4 On Thu, Jul 24, 2003 at 02:23:07PM +0800, Justin Clift wrote: > Gavin Sherry wrote: > <snip> > > Some more quotes would be great. Bruce, Tom, Peter, anyone? > > How about Andrew Sullivan, from Afilias? Just for the record, I am _never_ allowed to speak for Afilias. There's a whole communications department that handles that, and I'm am nowise competent to stay "on message". But I've forwarded something prepared by the communications folks. A -- ---- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M2P 2A8 +1 416 646 3304 x110 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Robert, > > As a thought, is it worth mentioning that there'll be a "commercial > > grade" proper Open Source PostgreSQL replication system available > > simultaneous to the 7.4 release? It's one of those things that is often > > asked about in higher-end installations, so letting people know in the > > press release (widest possible audience) makes sense. > > I'd rather spin it off as its own press release... Hmmm ... don't think I agree. The donation of eRServer is our "sexiest" feature for 7.4, and one of 3-4 items to make the press pay attention to the release. Also, if we send two releases within 2 weeks of each other, 1) Most reporters won't read them both, and 2) we won't get both of them together in time. But I'm willing to be persuaded, especially if you/somebody has text prepared for a release around eRServer that will go out this week. -- Josh Berkus Aglio Database Solutions San Francisco
On Thu, 24 Jul 2003, Josh Berkus wrote: > Robert, > > > > As a thought, is it worth mentioning that there'll be a "commercial > > > grade" proper Open Source PostgreSQL replication system available > > > simultaneous to the 7.4 release? It's one of those things that is often > > > asked about in higher-end installations, so letting people know in the > > > press release (widest possible audience) makes sense. > > > > I'd rather spin it off as its own press release... > > Hmmm ... don't think I agree. The donation of eRServer is our "sexiest" > feature for 7.4, and one of 3-4 items to make the press pay attention to the > release. > > Also, if we send two releases within 2 weeks of each other, > 1) Most reporters won't read them both, and > 2) we won't get both of them together in time. No. We'll get two stories. I'd run it seperately. Gavin
Robert, PGadvocates First of all, thanks for keeping track of all these changes! I was not looking forward to combing through all of the last 3 days' email. Thank you. However, I've been thinking some about the tone of the press release. Currently, what we have is essentially the technical announcement, "dumbed down" for the general press. While this gives us the correct content, it lacks "punch" that will interest reporters. Or, as Heather put it: > please let me know. From what I've seen so far I'd suggest tightening up the > lead and adding in the one big idea as to why 7.4 is important. Basically my > experience has been that you need to say everything in a short and concise > lead or the reporter doesn't even move his mouse to scroll down before > hitting the delete button :) As such, I think we need to re-draft the press release to put the "big news" stuff at the top and the "unrelated" detail at the bottom. And what's our "big news"? Well, the combined fixes and enhancements in 7.4, perhaps for the first time, really puts PostgreSQL's core functionality on even footing with Oracle and DB2 for large enterprise needs. Particularly I am thinking of: -- planner improvements for speed -- index-FSM means that a well-tuned 7.4 database no longer has to lock any tables ever for maintainence; true 99.99% uptime at last. -- donation of eRServer gives us a "battle-tested" replication solution -- read-only transaction setting improves multiuser security -- 64 bit support including Opteron -- new wire protocol speeds transfer of large objects Secondary to that but also important to "punch up" are the features that make it easier for enterprise to transition from proprietary databases: -- error reporting re-design allows vastly improved handling of errors by middleware for large distributed applications, especially since we use SQL-standard error codes -- join rewrite makes an easier transition for MS SQL & Sybase apps -- multibyte regex broadens our international support -- improved Tsearch exceeds MySQL's FTI and MSSQL's FTS; and, most importantly: -- reorganized and improved documentation makes the transition to PostgreSQL easier than it ever has been before. The other features/improvements, while important to our internal community, aren't going to make sense to most reporters. Instead, we need to tell a story -- a simple story -- which says: "Evaluate and switch to PostgreSQL now, it will be easy and we're just as good as the Big Guys." Am I making any sense? -- -Josh Berkus Aglio Database Solutions San Francisco
On 24 Jul 2003 at 17:13, Josh Berkus wrote: > The other features/improvements, while important to our internal community, > aren't going to make sense to most reporters. Instead, we need to tell a > story -- a simple story -- which says: > "Evaluate and switch to PostgreSQL now, it will be easy and we're just as good > as the Big Guys." That is a good one. Even if we add that single statement to original draft, it would be a good enough addition. Of course what you say is also very good.. Bye Shridhar -- Magpie, n.: A bird whose theivish disposition suggested to someone that it might be taught to talk. -- Ambrose Bierce, "The Devil's Dictionary"
On Thursday 24 July 2003 06:36, Robert Treat wrote: > Significant advances in PostgreSQL version 7.4 include: Several products create a portfolio effect. Example: - Windows + Internet Explorer + Outlook - Excel + Word + Powerpoint - Mysql + Php server + Apache - Photoshop + Illustrator + ... Therefore, why not mention eRServer, pgAdmin3 and PhpPgAdmin3 and the upcoming release of a Windows port? "PostgreSQL 7.4 will be shortly followed by the release of a native Windows port end of Q4. At this time, we plan to bundle PostgreSQL with eRServer (powerfull replication solution), pgAdmin3 (multi-platform graphical administration tool) and PhpPgAdmin (Web administration interface) delivered in separate installer. Our goal is to answer 95% of needs of %95 of users and become the standard database solution in the world." Regards, Jean-Michel
"Just as good as the big guys" makes us sound smaller and of minor interest. Aren't we one of the grown ups? When do we get to be grown up? --elein On Thu, Jul 24, 2003 at 05:13:34PM -0700, Josh Berkus wrote: > Robert, PGadvocates > > First of all, thanks for keeping track of all these changes! I was not > looking forward to combing through all of the last 3 days' email. Thank you. > > However, I've been thinking some about the tone of the press release. > Currently, what we have is essentially the technical announcement, "dumbed > down" for the general press. While this gives us the correct content, it > lacks "punch" that will interest reporters. > > Or, as Heather put it: > > please let me know. From what I've seen so far I'd suggest tightening up the > > lead and adding in the one big idea as to why 7.4 is important. Basically my > > experience has been that you need to say everything in a short and concise > > lead or the reporter doesn't even move his mouse to scroll down before > > hitting the delete button :) > > As such, I think we need to re-draft the press release to put the "big news" > stuff at the top and the "unrelated" detail at the bottom. And what's our > "big news"? > > Well, the combined fixes and enhancements in 7.4, perhaps for the first time, > really puts PostgreSQL's core functionality on even footing with Oracle and > DB2 for large enterprise needs. Particularly I am thinking of: > -- planner improvements for speed > -- index-FSM means that a well-tuned 7.4 database no longer has to lock any > tables ever for maintainence; true 99.99% uptime at last. > -- donation of eRServer gives us a "battle-tested" replication solution > -- read-only transaction setting improves multiuser security > -- 64 bit support including Opteron > -- new wire protocol speeds transfer of large objects > > Secondary to that but also important to "punch up" are the features that make > it easier for enterprise to transition from proprietary databases: > -- error reporting re-design allows vastly improved handling of errors by > middleware for large distributed applications, especially since we use > SQL-standard error codes > -- join rewrite makes an easier transition for MS SQL & Sybase apps > -- multibyte regex broadens our international support > -- improved Tsearch exceeds MySQL's FTI and MSSQL's FTS; > and, most importantly: > -- reorganized and improved documentation makes the transition to PostgreSQL > easier than it ever has been before. > > The other features/improvements, while important to our internal community, > aren't going to make sense to most reporters. Instead, we need to tell a > story -- a simple story -- which says: > "Evaluate and switch to PostgreSQL now, it will be easy and we're just as good > as the Big Guys." > > Am I making any sense? > > -- > -Josh Berkus > Aglio Database Solutions > San Francisco > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend >
> - Takes full advantage of large (>4GB) memory configurations on > numerous 64 bit platforms including AMD Opteron, HP/Compaq Alpha, > Sun UltraSPARC, MIPS, PA-RISC, and RS6000* This bullet is really lacking punch now. 64 bit CPUs aren't used _just_ for additional memory access. I didn't look too closely to see when they came in (before or after this email), but there were a few quotes and bits about 64bit platforms that had better ring than this. As it stands, I read, "we run on wherever GCC and the OS can run," which is true, but neglects that it's somewhat battle proven on Opteron and the other CPU's/OS'es mentioned. We really do _support_ Opteron in the sense that there are #ifdef's in our code to make sure that performance on Opteron doesn't suck(tm). > - Adds support for the AMD Opteron, increasing the list of 64bit > platforms supported. Supported 64bit platforms include HP/Compaq > Alpha, Sun UltraSPARC, MIPS, PA-RISC, RS6000*, and AMD Opteron. > - New wire protocol (version 3) increases the speed of data transfers Did this ever get verified? The reason I'm pretty sure this is true is there is a lack of need to encode/decode data off the wire. src/backend/libpq/pqformat.c: * Note in particular the distinction between "raw data" and "text"; raw data * is message protocol characters and binary values that are not subject to * character set conversion, while text is converted by character encoding * rules. Lastly, as someone else said, more quotes would be good if this is going to mainstream/conventional media sources and not just Open Source press outlets. I may have a connection to the Seattle Times, fwiw... still exploring that avenue though... -sc -- Sean Chittenden
> > - Read only transactions, bringing a greater level of security to web and > > enterprise applications by protecting data from modification. This should be removed. Even though I added it to the press release, I've just realised it's not really a security measure against SQL injection since injected code can just specify 'SET TRANSACTION READ WRITE'. We should still mention it, but not as a security measure. Gavin
On Saturday 26 July 2003 17:04, Sean Chittenden wrote:
> > - Takes full advantage of large (>4GB) memory configurations on
> > numerous 64 bit platforms including AMD Opteron, HP/Compaq Alpha,
> > Sun UltraSPARC, MIPS, PA-RISC, and RS6000*
>
> This bullet is really lacking punch now. 64 bit CPUs aren't used
> _just_ for additional memory access. I didn't look too closely to see
> when they came in (before or after this email), but there were a few
> quotes and bits about 64bit platforms that had better ring than this.
> As it stands, I read, "we run on wherever GCC and the OS can run,"
> which is true, but neglects that it's somewhat battle proven on
> Opteron and the other CPU's/OS'es mentioned. We really do _support_
> Opteron in the sense that there are #ifdef's in our code to make sure
> that performance on Opteron doesn't suck(tm).
>
> > - Adds support for the AMD Opteron, increasing the list of 64bit
> > platforms supported. Supported 64bit platforms include HP/Compaq
> > Alpha, Sun UltraSPARC, MIPS, PA-RISC, RS6000*, and AMD Opteron.
> >
- Is now optmized for the AMD Opteron, increasing the family of 64-bit
platforms supported which already includes HP/Compaq, Alpha, Sun UltraSPARC,
MIPS, PA-RISC, and RS6000*. 64-bit platforms are designed to be a new class
of high-performance computing, with greater levels of computing power and
scaleability needed for enterprise level systems.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Sat, 2003-07-26 at 21:31, Gavin Sherry wrote:
> > > - Read only transactions, bringing a greater level of security to web and
> > > enterprise applications by protecting data from modification.
>
> This should be removed. Even though I added it to the press release, I've
> just realised it's not really a security measure against SQL injection
> since injected code can just specify 'SET TRANSACTION READ WRITE'. We
> should still mention it, but not as a security measure.
>
Aside from spec compliance, whats the bonus for having it then? Or put a
better way, why/when would I want to use this?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> "Just as good as the big guys" makes us sound smaller and > of minor interest. > --elein The punch is adding the statement "free". Otherwise you're correct- we're just a moderate fish in a big pond. (Yawn.) In an old InfoWorld column, Robert Lewis noted that "Less Filling, Tastes Great" is an example of both a great mission statement and marketing hook. Along the same lines, a good opening hook might be: "An Enterprise-Level Database, Free." I do both marketing and programming at our company. As a programmer, I'm often tempted to go for the complete explanation that technical folks demand. But everyone else in the world wants a single line that tells them why they should bother with the rest. So while the rest of this discussion is important for those that get past the top line, I suggest that the top line be intriguing and purposely incomplete. Resist the temptation to answer every question- questions are what we want to provoke. -Nick
Robert, > Aside from spec compliance, whats the bonus for having it then? Or put a > better way, why/when would I want to use this? One scenario: You have 5 PostgreSQL servers connecting to one SAN or NAS which is your /data directory for a single database. You use your middleware to distribute requests among the servers; One server gets data write requests, the other 4 get read-only requests. However, you want to make sure that if your middleware hiccups you don't corrupt the database files. For this, setting 4 of the servers to "Read Only Transactions" would be useful. -- -Josh Berkus Aglio Database Solutions San Francisco
On Mon, 28 Jul 2003, Josh Berkus wrote: > Robert, > > > Aside from spec compliance, whats the bonus for having it then? Or put a > > better way, why/when would I want to use this? > > One scenario: You have 5 PostgreSQL servers connecting to one SAN or NAS > which is your /data directory for a single database. You use your > middleware to distribute requests among the servers; One server gets data > write requests, the other 4 get read-only requests. > > However, you want to make sure that if your middleware hiccups you don't > corrupt the database files. For this, setting 4 of the servers to "Read Only > Transactions" would be useful. That will not work because the writer maintains a cache of data to write and worse case scenario, the data only gets written to data files every CHECKPOINT. This means that your four readers are returning corrupted data. Moreover, the readers do not expect the data to change undernearth them, as they maintain caches and would have no mechanism to invalidate that cache upon external file system changes. Load balancing and clustering is hard :P. It is, however, generally used with READ UNCOMMITTED transactions. In fact, SQL99 necessitates READ ONLY for READ UNCOMMITTED isolation level (READ UNCOMMITTED allows you to see uncommitted data modifications). Gavin
Nick Fankhauser wrote: <snip> > "An Enterprise-Level Database, Free." How about: "An Enterprise-Level Database, Saving You Money" ? Regards and best wishes, Justin Clift <snip>
On Mon, 2003-07-28 at 19:16, Gavin Sherry wrote:
> On Mon, 28 Jul 2003, Josh Berkus wrote:
>
> > Robert,
> >
> > > Aside from spec compliance, whats the bonus for having it then? Or put a
> > > better way, why/when would I want to use this?
> >
> > One scenario: You have 5 PostgreSQL servers connecting to one SAN or NAS
> > which is your /data directory for a single database. You use your
> > middleware to distribute requests among the servers; One server gets data
> > write requests, the other 4 get read-only requests.
> >
> > However, you want to make sure that if your middleware hiccups you don't
> > corrupt the database files. For this, setting 4 of the servers to "Read Only
> > Transactions" would be useful.
>
> That will not work because the writer maintains a cache of data to write
> and worse case scenario, the data only gets written to data files every
> CHECKPOINT. This means that your four readers are returning corrupted
> data. Moreover, the readers do not expect the data to change undernearth
> them, as they maintain caches and would have no mechanism to invalidate
> that cache upon external file system changes. Load balancing and
> clustering is hard :P.
>
> It is, however, generally used with READ UNCOMMITTED transactions. In
> fact, SQL99 necessitates READ ONLY for READ UNCOMMITTED isolation level
> (READ UNCOMMITTED allows you to see uncommitted data modifications).
>
I was really looking for the nie one-line answer that might go in a
press release, but I don't think this is one of those types of features.
Sure, it can be useful in some places, and it adds to spec compliance,
but I don't think it is big enough to need mentioning in the press
release.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> > > - Takes full advantage of large (>4GB) memory configurations on > > > numerous 64 bit platforms including AMD Opteron, HP/Compaq Alpha, > > > Sun UltraSPARC, MIPS, PA-RISC, and RS6000* > > > > This bullet is really lacking punch now. 64 bit CPUs aren't used > > _just_ for additional memory access. I didn't look too closely to see > > when they came in (before or after this email), but there were a few > > quotes and bits about 64bit platforms that had better ring than this. > > As it stands, I read, "we run on wherever GCC and the OS can run," > > which is true, but neglects that it's somewhat battle proven on > > Opteron and the other CPU's/OS'es mentioned. We really do _support_ > > Opteron in the sense that there are #ifdef's in our code to make sure > > that performance on Opteron doesn't suck(tm). > > > > > - Adds support for the AMD Opteron, increasing the list of 64bit > > > platforms supported. Supported 64bit platforms include HP/Compaq > > > Alpha, Sun UltraSPARC, MIPS, PA-RISC, RS6000*, and AMD Opteron. > > > > > - Is now optmized for the AMD Opteron, increasing the family of 64-bit > platforms supported which already includes HP/Compaq, Alpha, Sun UltraSPARC, > MIPS, PA-RISC, and RS6000*. 64-bit platforms are designed to be a new class > of high-performance computing, with greater levels of computing power and > scaleability needed for enterprise level systems. Oh, that's the money shot! Very nice. -sc -- Sean Chittenden
Justin Clift wrote: > Nick Fankhauser wrote:[...] > > "An Enterprise-Level Database, Free." > > How about:[...] > "An Enterprise-Level Database, Saving You Money" Curious about the term "Enterprise-Level" vs. "Enterprise"? Sybase calls theirs an "Enterprise Database for Linux" http://www.sybase.com/detail/1,6904,1024137,00.html http://www.sybase.com/detail?id=1019336 and MSFT & Borland use that phrase as well... http://www.borland.com/news/press_releases/2003/06_02_03_borland_and_microsoft_team_to_deliver_solution.html For my own enlightenment, do the terms mean something different? Ron
Ron, > Curious about the term "Enterprise-Level" vs. "Enterprise"? > For my own enlightenment, do the terms mean something different? No. -- Josh Berkus Aglio Database Solutions San Francisco
Heather, > I'm Afilias' Communications Manager and try to keep up with the discussion > on the list for areas where it is appropriate for us to help out. If anyone > ever has any questions for us regarding press/marketing please feel free to > direct them my way. Can we have a 20 to 30-word blurb about who Afilias is with a link for the bottom of the Press Release? e.g, AFILIAS LIMITED: the power behind the .info and .org TLDs, .... -- Josh Berkus Aglio Database Solutions San Francisco