Thread: 7.4 Press Release -- Draft #3

The PostgreSQL Global Development Group is pleased to announce the
availability of version 7.4 of the PostgreSQL relational database
management system (RDBMS). This significant 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 our 7.3
release in November 2002.

Significant advances in the new version include:

   - A complete redesign of error logging and reporting, providing
     developers with an SQL99 compliant mechanism for debugging and
     troubleshooting, while at the same time providing users real
     time suggestions on how to avoid error conditions in their
     applications.

   - A redesign of subquery handling with the IN() clause resulting
     in considerable speed improvements.

   - The implementation of SQL99 compliant Information Schema,
     providing developers with database, type, object, and
     configuration information in a standards compliant way.

   - Statement level triggers, enabling developers and users to define
     and customized behavior of the database when data is stored and
     manipulated.

   - Read only transactions, which bring a greater level of
     security to web and enterprise applications by protecting data
     from modification.

   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
   - An auto-vacuum feature to help simplify database maintenance

As well as many other features and improvements.


A Timely Release

In making the release, the PostgreSQL Global Development Group had to
balance the large number of features planned for release with a
consistent release cycle, which provides loyal users with enhancements
as quickly as possible. <Insert quote from core developer reinforcing
this>

<Insert quote from user(s) about business critical nature of features
released in this version>

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.3 can be found in the
HISTORY file included with the release, or available on the web at:
    <insert url for changelog>

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/

--- outstanding issues --
1. Should we drop the "A timely release" paragraph?

2. Need end - user quotes

3. Need a URL for the changelog

4. Still looking for new companies

5. no mention of replication until the discussion finishes on -hackers.


Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Monday 21 July 2003 14:48, 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 significant 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 our 7.3
> release in November 2002.
>
> Significant advances in the new version include:
>
>    - A complete redesign of error logging and reporting, providing
>      developers with an SQL99 compliant mechanism for debugging and
>      troubleshooting, while at the same time providing users real
>      time suggestions on how to avoid error conditions in their
>      applications.
>
>    - A redesign of subquery handling with the IN() clause resulting
>      in considerable speed improvements.
>
>    - The implementation of SQL99 compliant Information Schema,
>      providing developers with database, type, object, and
>      configuration information in a standards compliant way.
>
>    - Statement level triggers, enabling developers and users to define
>      and customized behavior of the database when data is stored and
>      manipulated.
>
>    - Read only transactions, which bring a greater level of
>      security to web and enterprise applications by protecting data
>      from modification.
>
>    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
>    - An auto-vacuum feature to help simplify database maintenance
>
> As well as many other features and improvements.
>
>
> A Timely Release
>
> In making the release, the PostgreSQL Global Development Group had to
> balance the large number of features planned for release with a
> consistent release cycle, which provides loyal users with enhancements
> as quickly as possible. <Insert quote from core developer reinforcing
> this>
>
> <Insert quote from user(s) about business critical nature of features
> released in this version>
>
> 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.3 can be found in the
> HISTORY file included with the release, or available on the web at:
>     <insert url for changelog>
>



************************************************
A complete list of changes in PostgreSQL version 7.4
............................
************************************************



> 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/
>
> --- outstanding issues --
> 1. Should we drop the "A timely release" paragraph?
>
> 2. Need end - user quotes
>
> 3. Need a URL for the changelog
>
> 4. Still looking for new companies
>
> 5. no mention of replication until the discussion finishes on -hackers.
>
>
> Robert Treat

--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx:  250.763.1759
http://www.wavefire.com

Robert Treat wrote:
>    Other improvements include:
>    - Performance improvements for data warehousing

I still wonder what specific features we'd point to as "data
warehousing" improvements?

Joe

Joe Conway wrote:
> Robert Treat wrote:
>>    Other improvements include:
>>    - Performance improvements for data warehousing
>
> I still wonder what specific features we'd point to as "data
> warehousing" improvements?
>

Sorry -- I just read that again. Nevermind :-)

Joe

Robert,

> 1. Should we drop the "A timely release" paragraph?

I'd kill it.

> 2. Need end - user quotes

Want me to poll GENERAL etc?

> 4. Still looking for new companies

Can't help you ... under NDA.
Dammit.

> 5. no mention of replication until the discussion finishes on -hackers.

You mean it's still a possibility?


--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

On Mon, 2003-07-21 at 18:18, Josh Berkus wrote:
> Robert,
>
> > 1. Should we drop the "A timely release" paragraph?
>
> I'd kill it.
>

ok

> > 2. Need end - user quotes
>
> Want me to poll GENERAL etc?
>

we're just turnin' up tumbleweeds here... go for it.

>
> > 5. no mention of replication until the discussion finishes on -hackers.
>
> You mean it's still a possibility?
>

A couple of people have asked about this so let me expand on this
ambiguous note. There a couple of folks, led by Andrew Sullivan, who are
looking at releasing the replication code first used by Afilias, Inc
(the folks running the .org/.info domains). I should point out that it
is not the latest and greatest version of the code, and that it is not
as good as what you would get if you were to purchase the commercial
version of ERServer (at least that's what I've been told), but it has
been tested in an enterprise level setting so would cover a lot of
ground in the replication arena if it were to be included. I want to
stress that as of now there is nothing in CVS, so as far as we're
concerned, it's all vaporware. If they do get it in we'll we can rework
the press release, but until then it's best to proceed with things as
planned.


Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Mon, 21 Jul 2003, Josh Berkus wrote:

> Robert,
>
> > 1. Should we drop the "A timely release" paragraph?
>
> I'd kill it.

You've got to look at what press releases are used for. I added that
paragraph for this reason: Journos use press releaes in three
ways. i) Delete ii) Rewrite facts as a product announcement iii) Try to
make a story out of it.

Ultimately, we will get the most press out of a story about Postgres. If
we do not have a paragraph or two in the press release to give journos a
story, we wont get one. The "A Timely Release" thing was nothing and can
be replaced. But what with?

Thanks,

Gavin

> The PostgreSQL Global Development Group is pleased to announce the
> availability of version 7.4 of the PostgreSQL relational database
> management system (RDBMS).

Case -> Relational Database Management System (RDBMS).

> This significant release

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 our 7.3 release in November
> 2002.

nix "our 7.3 release in November 2002" and replace with just,
"PostgreSQL 7.3".  The date for when 7.3 was released isn't needed
since we've just given the reader a rough time line with the amount of
time between releases (9 months).

> Significant advances in the new version include:
>
>    - A complete redesign of error logging and reporting, providing
>      developers with an SQL99 compliant mechanism for debugging and
>      troubleshooting, while at the same time providing users real
>      time suggestions on how to avoid error conditions in their
>      applications.
>
>    - A redesign of subquery handling with the IN() clause resulting
>      in considerable speed improvements.

Might be worth while mentioning something like the following to go
with the above point:

      Other additional planner improvements have brought PostgreSQL's
      performance inline with the large RDBMS vendors.

>    - The implementation of SQL99 compliant Information Schema,
>      providing developers with database, type, object, and
>      configuration information in a standards compliant way.
>
>    - Statement level triggers, enabling developers and users to define
>      and customized behavior of the database when data is stored and
>      manipulated.
>
>    - Read only transactions, which bring a greater level of
>      security to web and enterprise applications by protecting data
>      from modification.

How about "Explicit JOINs no longer constrain query plan, unless
JOIN_COLLAPSE_LIMIT = 1"?  This is kind of a big deal for MS SQL
users/organizations..  Targeting their audience would be good and
increase our user uptake from their dept.

    When enabled, the planner can now automatically optimize the
    join order of queries: a feature found in a few commercial
    RDBMS's that can reduce the time busy DBAs need to spend
    optimizing queries.

>    Other improvements include:
>    - Performance improvements for data warehousing

Does this mean the NUMERIC handling?

>    - Enhanced implementation of functional indexes
>    - Addition of polymorphic function arguments and return types
>    - Significant enhancements to array data types
>    - Completely overhauled and simplified documentation
>    - An auto-vacuum feature to help simplify database maintenance

Update multi-byte regexp package is a big deal for intl users.

If it gets mentioned, 24/7 installations are going to really push for
upgrading to this release because of the index growth problem that was
quenched in this version.  Something like:

    Infinite index growth can now be prevented with frequent VACUUMs

Mentioning the protocol change is also probably important here.

    New wire protocol (version 3) increases the speed of data transfers.

I haven't benchmarked it, but from what I've read of the protocol
spec, it likely does.  Tom might want to confirm this.  More efficient
BYTEA transfers is a big deal for the medical community that's storing
MRIs in PostgreSQL.

Mentioning support for AMD's Opteron would also be a good bit to have
since that says, "we're a safe database to base your business around
because we move with the times and support cutting edge hardware, even
though the project has been around forever."

> As well as many other features and improvements.
>
>
> <Insert quote from user(s) about business critical nature of features
> released in this version>
>
> 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.3 can be found in the
> HISTORY file included with the release, or available on the web at:
>     <insert url for changelog>
>
> 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/
>
> --- outstanding issues --
> 1. Should we drop the "A timely release" paragraph?

Yes.

> 3. Need a URL for the changelog

http://www.postgresql.org/docs/7.4static/release.html#RELEASE-7-4


Sorry for putting on my editor hat so late in the announcement
drafting process. -sc

--
Sean Chittenden

On Mon, 21 Jul 2003, Sean Chittenden wrote:

> > The PostgreSQL Global Development Group is pleased to announce the
> > availability of version 7.4 of the PostgreSQL relational database
> > management system (RDBMS).
>
> Case -> Relational Database Management System (RDBMS).
>
> > This significant release
>
> 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 our 7.3 release in November
> > 2002.
>
> nix "our 7.3 release in November 2002" and replace with just,
> "PostgreSQL 7.3".  The date for when 7.3 was released isn't needed
> since we've just given the reader a rough time line with the amount of
> time between releases (9 months).
>
> > Significant advances in the new version include:
> >
> >    - A complete redesign of error logging and reporting, providing
> >      developers with an SQL99 compliant mechanism for debugging and
> >      troubleshooting, while at the same time providing users real
> >      time suggestions on how to avoid error conditions in their
> >      applications.
> >
> >    - A redesign of subquery handling with the IN() clause resulting
> >      in considerable speed improvements.
>
> Might be worth while mentioning something like the following to go
> with the above point:
>
>       Other additional planner improvements have brought PostgreSQL's
>       performance inline with the large RDBMS vendors.

Hmm. Pretty general statement.

>
> >    - The implementation of SQL99 compliant Information Schema,
> >      providing developers with database, type, object, and
> >      configuration information in a standards compliant way.
> >
> >    - Statement level triggers, enabling developers and users to define
> >      and customized behavior of the database when data is stored and
> >      manipulated.
> >
> >    - Read only transactions, which bring a greater level of
> >      security to web and enterprise applications by protecting data
> >      from modification.
>
> How about "Explicit JOINs no longer constrain query plan, unless
> JOIN_COLLAPSE_LIMIT = 1"?  This is kind of a big deal for MS SQL
> users/organizations..  Targeting their audience would be good and
> increase our user uptake from their dept.
>
>     When enabled, the planner can now automatically optimize the
>     join order of queries: a feature found in a few commercial
>     RDBMS's that can reduce the time busy DBAs need to spend
>     optimizing queries.
>

Good point, I'll try to work into a user friendly format.

> >    Other improvements include:
> >    - Performance improvements for data warehousing
>
> Does this mean the NUMERIC handling?

I have the enhanced array support and GROUP BY improvements.

>
> >    - Enhanced implementation of functional indexes
> >    - Addition of polymorphic function arguments and return types
> >    - Significant enhancements to array data types
> >    - Completely overhauled and simplified documentation
> >    - An auto-vacuum feature to help simplify database maintenance
>
> Update multi-byte regexp package is a big deal for intl users.

Good point.

>
> If it gets mentioned, 24/7 installations are going to really push for
> upgrading to this release because of the index growth problem that was
> quenched in this version.  Something like:
>
>     Infinite index growth can now be prevented with frequent VACUUMs
>
> Mentioning the protocol change is also probably important here.
>
>     New wire protocol (version 3) increases the speed of data transfers.
>
> I haven't benchmarked it, but from what I've read of the protocol
> spec, it likely does.  Tom might want to confirm this.  More efficient
> BYTEA transfers is a big deal for the medical community that's storing
> MRIs in PostgreSQL.

Might be a bit specific for a media release. Remember, we're also doing a
detailed user-focussed announcement.

>
> Mentioning support for AMD's Opteron would also be a good bit to have
> since that says, "we're a safe database to base your business around
> because we move with the times and support cutting edge hardware, even
> though the project has been around forever."

Excellent point.

Gavin

People:

First, let me apologize for the confusion I caused.  I was out of the country
on July 15th, so I thought we'd gone beta on schedule ... and only had a week
to finish the press release.

But I'm glad we've got the ball rolling now.

> How about "Explicit JOINs no longer constrain query plan, unless
> JOIN_COLLAPSE_LIMIT = 1"?  This is kind of a big deal for MS SQL
> users/organizations..  Targeting their audience would be good and
> increase our user uptake from their dept.

Hmmm ....

    Optional explicit join rewriting by the query planner, allowing an
        easy transition for MS SQL Server users.

> >    Other improvements include:
> >    - Performance improvements for data warehousing
>
> Does this mean the NUMERIC handling?

No, mostly Hash Aggregates for faster GROUP BY queries.
Perhaps we should clarify?

    - Performance improvements in aggregates for faster 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

How "overhauled" is the documentation?   If it's a lot, this would be a "major
feature".

> >    - An auto-vacuum feature to help simplify database maintenance
>
> Update multi-byte regexp package is a big deal for intl users.
>
> If it gets mentioned, 24/7 installations are going to really push for
> upgrading to this release because of the index growth problem that was
> quenched in this version.  Something like:
>
>     Infinite index growth can now be prevented with frequent VACUUMs

I'd suggest:
    Improved index maintainence for high availability databases.

One more re-write from me this week.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

> > Might be worth while mentioning something like the following to go
> > with the above point:
> >
> >       Other additional planner improvements have brought PostgreSQL's
> >       performance inline with the large RDBMS vendors.
>
> Hmm. Pretty general statement.

It is, but on several occasions Tom has mentioned that through red
hat, he's heard that 7.4 has query planner related performance
enhancements that make PostgreSQL competitive to Oracle.  I tried to
convey that as best as possible w/o saying anything technical.
Basically I was trying to say, "re-evaluate PostgreSQL if you tried
it, but it wasn't quite fast enough and went with Oracle: we should be
as fast if not faster and we're certainly cheaper."

> > Mentioning the protocol change is also probably important here.
> >
> >     New wire protocol (version 3) increases the speed of data transfers.
> >
> > I haven't benchmarked it, but from what I've read of the protocol
> > spec, it likely does.  Tom might want to confirm this.  More
> > efficient BYTEA transfers is a big deal for the medical community
> > that's storing MRIs in PostgreSQL.
>
> Might be a bit specific for a media release. Remember, we're also
> doing a detailed user-focussed announcement.

The BYTEA bit isn't supposed to show up in the release, only "the wire
protocol has changed and it should be much faster to transfer big
images/files in and out of the database. *smacks medical community up
side the head* Hey you guys, check us out and use PostgreSQL: we do
what you need pretty well and aren't dog slow at big files like other
RDBMSs servers."

-sc

--
Sean Chittenden

Sean,

> Basically I was trying to say, "re-evaluate PostgreSQL if you tried
> it, but it wasn't quite fast enough and went with Oracle: we should be
> as fast if not faster and we're certainly cheaper."

Why not say that?

Sean Chittenden, PostgreSQL developer and DBA for <your employer>, suggests,
"If you tried PostgreSQL before and it wasn't quite fast enough, and you went
with Oracle, it's time to re-evaluate.   We should be just as fast if not
faster, and we're certainly cheaper."

This is going to the *press*, not the geek community.  Let's be direct and
explicit.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

On Mon, 21 Jul 2003, Robert Treat wrote:

> A couple of people have asked about this so let me expand on this
> ambiguous note. There a couple of folks, led by Andrew Sullivan, who are
> looking at releasing the replication code first used by Afilias, Inc
> (the folks running the .org/.info domains). I should point out that it
> is not the latest and greatest version of the code, and that it is not
> as good as what you would get if you were to purchase the commercial
> version of ERServer (at least that's what I've been told), but it has
> been tested in an enterprise level setting so would cover a lot of
> ground in the replication arena if it were to be included. I want to
> stress that as of now there is nothing in CVS, so as far as we're
> concerned, it's all vaporware. If they do get it in we'll we can rework
> the press release, but until then it's best to proceed with things as
> planned.

eRServer v1.0 is going to be released open source (we wanted to do so
before I went on holidays, but we have a bit of docs work to do up) ...
but, it won't be included *in* the distribution itself, but as a seperate
package ...

> > Basically I was trying to say, "re-evaluate PostgreSQL if you tried
> > it, but it wasn't quite fast enough and went with Oracle: we should be
> > as fast if not faster and we're certainly cheaper."
>
> Why not say that?
>
> Sean Chittenden, PostgreSQL developer and DBA for <your employer>,
> suggests, "If you tried PostgreSQL before and it wasn't quite fast
> enough, and you went with Oracle, it's time to re-evaluate.  We
> should be just as fast if not faster, and we're certainly cheaper."

For various legal reasons, if someone else stepped forward and wanted
to attach their name to that quote, I'd feel a bit more comfortable.
If no one does before we release, hit me up and I'll craft something
that conveys that same meaning.

-sc

--
Sean Chittenden

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> over 100 developers and

Should be "hundreds of "


> Significant advances in the new version include:

Since we last mentioned 7.3 at the end of the last paragraph,
a reminder of which version might sound better:

"Significant advances in PostgreSQL version 7.4 include:"


> Read only transactions, which bring a

Should be "bringing a" to sync with the previous paragraphs.


> while at the same time providing users real time suggestions

Reads better as "providing users with real time..."


> The implementation of SQL99 compliant Information Schema,

Should be "implementation of a SQL99..."


> Statement level triggers, enabling developers and users to define
> and customized behavior of the database when data is stored and
> manipulated.

Could have sworn I reported this one last time. Should be
"define and customize". The whole paragraph is also a little
awkward, IMO.


> A complete list of changes in PostgreSQL version 7.3

Should be 7.4.


> rock solid performance record

Perhaps just "solid"?


> PostgreSQL is available under a BSD License for both commercial
> and non-commercial use.

Expand on this license or link to an explanatory page for people
who may not know the advantages of this.



> How "overhauled" is the documentation?

I believe that this is mostly the layout, not the content.


- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200307220902

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE/HTrmvJuQZxSWSsgRAqR1AJ46luoTcbP+yeTjL6Dgn5SPvTuOVwCgopWZ
bFN61OD071p2VE1l2Tw+oOc=
=1D1E
-----END PGP SIGNATURE-----

On Mon, 2003-07-21 at 19:40, Sean Chittenden wrote:
<snip>
> >
> >    - A redesign of subquery handling with the IN() clause resulting
> >      in considerable speed improvements.
>
> Might be worth while mentioning something like the following to go
> with the above point:
>
>       Other additional planner improvements have brought PostgreSQL's
>       performance inline with the large RDBMS vendors.
>

Improvements to the query planner, including a redesign of subquery
handling with the IN() clause, resulting in considerable speed
improvements.


<snip>
>
> How about "Explicit JOINs no longer constrain query plan, unless
> JOIN_COLLAPSE_LIMIT = 1"?  This is kind of a big deal for MS SQL
> users/organizations..  Targeting their audience would be good and
> increase our user uptake from their dept.
>
>     When enabled, the planner can now automatically optimize the
>     join order of queries: a feature found in a few commercial
>     RDBMS's that can reduce the time busy DBAs need to spend
>     optimizing queries.
>

I don't like this because the planner already optimizes the join order
of queries for non explicit joins, and to me I have always looked at the
ability to ability to constrain query plans based on join order as
feature...

Josh wrote:
> Optional explicit join rewriting by the query planner,
> allowing an easy transition for MS SQL Server users.

I don't like that, because istm win32 would really make transition
easier, and I'd like to avoid bringing up thoughts of that...

Are there other databases that use this behavior?


>
> Mentioning the protocol change is also probably important here.
>
>     New wire protocol (version 3) increases the speed of data transfers.
>
> I haven't benchmarked it, but from what I've read of the protocol
> spec, it likely does.  Tom might want to confirm this.  More efficient
> BYTEA transfers is a big deal for the medical community that's storing
> MRIs in PostgreSQL.
>

If you can get Tom to confirm this, I would put it in.

> Mentioning support for AMD's Opteron would also be a good bit to have
> since that says, "we're a safe database to base your business around
> because we move with the times and support cutting edge hardware, even
> though the project has been around forever."
>

still thinking on this one... it's not new that we support 64bit
hardware.

>
> > 3. Need a URL for the changelog
>
> http://www.postgresql.org/docs/7.4static/release.html#RELEASE-7-4
>

I've proffered http://www.postgresql.org/docs/release/740.html to the
web group, which seems to have been found acceptable (at least no one
objected). Anyone want to create pages for all of the previous releases?

>
> Sorry for putting on my editor hat so late in the announcement
> drafting process. -sc
>

No problem, you've got some good suggestions here.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Mon, 2003-07-21 at 20:45, The Hermit Hacker wrote:
> On Mon, 21 Jul 2003, Robert Treat wrote:
>
> > A couple of people have asked about this so let me expand on this
> > ambiguous note. There a couple of folks, led by Andrew Sullivan, who are
> > looking at releasing the replication code first used by Afilias, Inc
> > (the folks running the .org/.info domains). I should point out that it
> > is not the latest and greatest version of the code, and that it is not
> > as good as what you would get if you were to purchase the commercial
> > version of ERServer (at least that's what I've been told), but it has
> > been tested in an enterprise level setting so would cover a lot of
> > ground in the replication arena if it were to be included. I want to
> > stress that as of now there is nothing in CVS, so as far as we're
> > concerned, it's all vaporware. If they do get it in we'll we can rework
> > the press release, but until then it's best to proceed with things as
> > planned.
>
> eRServer v1.0 is going to be released open source (we wanted to do so
> before I went on holidays, but we have a bit of docs work to do up) ...
> but, it won't be included *in* the distribution itself, but as a seperate
> package ...
>

The discussion seemed to be leaning toward contrib rather than gborg,
has a decision swung the other way?


Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Mon, 2003-07-21 at 23:13, Sean Chittenden wrote:
> > > Basically I was trying to say, "re-evaluate PostgreSQL if you tried
> > > it, but it wasn't quite fast enough and went with Oracle: we should be
> > > as fast if not faster and we're certainly cheaper."
> >
> > Why not say that?
> >
> > Sean Chittenden, PostgreSQL developer and DBA for <your employer>,
> > suggests, "If you tried PostgreSQL before and it wasn't quite fast
> > enough, and you went with Oracle, it's time to re-evaluate.  We
> > should be just as fast if not faster, and we're certainly cheaper."
>
> For various legal reasons, if someone else stepped forward and wanted
> to attach their name to that quote, I'd feel a bit more comfortable.
> If no one does before we release, hit me up and I'll craft something
> that conveys that same meaning.

You can use my name if you like (Rod Taylor with InQuent Technologies
Inc.).

Recently we evaluated databases for our new system (major rewrite of
'flagship' product) and went with PostgreSQL, though we will be
maintaining some of the older Oracle based DBs for some time.

> You can use my name if you like (Rod Taylor with InQuent Technologies
> Inc.).

"If you tried PostgreSQL before, and it wasn't quite fast enough, and you went
with Oracle, it's time to re-evaluate," suggests Rod Taylor of InQuent
Technologies. "We should be just as fast, if not faster, and we're certainly
cheaper."

--
Josh Berkus
Aglio Database Solutions
San Francisco

People,

Remember, everyone, this is a Press Release for the **trade press**.  It does
NOT pay to get too technical.   For example, I'd re-write the below as:

> Improvements to the query planner, including a redesign of subquery
> handling with the IN() clause, resulting in considerable speed
> improvements.

Improvements in subquery handling by the planner resulting in up to 400% speed
increases in some complex queries.

(the 400% is based on a couple of examples on -PERFORMANCE)

Even a trade reporter ... like the Linux Weekly News ... isn't likely to
understand " IN() subquery".

> > Optional explicit join rewriting by the query planner,
> > allowing an easy transition for MS SQL Server users.
>
> I don't like that, because istm win32 would really make transition
> easier, and I'd like to avoid bringing up thoughts of that...

Sure it would, but the from_collapse_order was a big deal to several former
MSSQL DBAs on our lists.

> Are there other databases that use this behavior?

Yes, Sybase.  Not sure about others.  I see where you're going:

Optional explicit join rewriting by the query planner,
allowing an easy transition for MS SQL Server and Sybase
users.

> > Mentioning support for AMD's Opteron would also be a good bit to have
> > since that says, "we're a safe database to base your business around
> > because we move with the times and support cutting edge hardware, even
> > though the project has been around forever."
>
> still thinking on this one... it's not new that we support 64bit
> hardware.

No, it's not.  I point out, though, that MySQL got a significant amount of
press milage out of their support for AIX last year ... even though we've had
it for 2 years.  Since we *do* have production-tested support for Opteron in
this release, we need to trumpet it loud and "grab the high ground."

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Tuesday 22 July 2003 09:13, Josh Berkus wrote:
> > You can use my name if you like (Rod Taylor with InQuent Technologies
> > Inc.).
>
> "If you tried PostgreSQL before, and it wasn't quite fast enough, and you
> went with Oracle, it's time to re-evaluate," suggests Rod Taylor of InQuent
> Technologies. "We should be just as fast, if not faster, and we're
> certainly cheaper."


You might want to change the possesive nature of this quote (WE should
be....), makes it sound like it's PostgreSQL making the claim, not a
user/DBA.


--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx:  250.763.1759
http://www.wavefire.com

People,

> > "If you tried PostgreSQL before, and it wasn't quite fast enough, and you
> > went with Oracle, it's time to re-evaluate," suggests Rod Taylor of
> > InQuent Technologies. "We should be just as fast, if not faster, and
> > we're certainly cheaper."
>
> You might want to change the possesive nature of this quote (WE should
> be....), makes it sound like it's PostgreSQL making the claim, not a
> user/DBA.

OK, then:
"If you tried PostgreSQL before, and it wasn't quite fast enough, and you
went with Oracle, it's time to re-evaluate," suggests Rod Taylor of
InQuent Technologies. "PostgreSQL should be just as fast, if not faster, and
it's certainly cheaper."

Also:   I may have a great quote from a Federal Reserve Bank (woo-hoo); I
waiting on confirmation.

Finally, more new features:

-- A new ranked preference system for the TSearch full text indexing module.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Tue, 2003-07-22 at 12:22, Josh Berkus wrote:
> > > Mentioning support for AMD's Opteron would also be a good bit to have
> > > since that says, "we're a safe database to base your business around
> > > because we move with the times and support cutting edge hardware, even
> > > though the project has been around forever."
> >
> > still thinking on this one... it's not new that we support 64bit
> > hardware.
>
> No, it's not.  I point out, though, that MySQL got a significant amount of
> press milage out of their support for AIX last year ... even though we've had
> it for 2 years.  Since we *do* have production-tested support for Opteron in
> this release, we need to trumpet it loud and "grab the high ground."
>

Well, that actually was news, since mysql didn't actually support aix
when they made that announcement. they also get mileage from trumpeting
subselects and transactions, should we toss that in as well?

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert,

> Well, that actually was news, since mysql didn't actually support aix
> when they made that announcement. they also get mileage from trumpeting
> subselects and transactions, should we toss that in as well?

If you're going to be sarcastic, please use smileys.

Our support for Opteron is news.  Nobody did it before three weeks ago, and
nobody announced it to the press since.  We also added a patch to 7.4 so that
it would support Opteron "out-of-the-tarball."

This is a "sexy" featurette that the press will like.   We should make sure
they know about it.

--
Josh Berkus
Aglio Database Solutions
San Francisco

I would replace 'should be' with 'is' and remove 'certainly' (or replace
with much) for a stronger statement...

Regards,
Merlin


-----Original Message-----
From: Darcy Buskermolen [mailto:darcy@wavefire.com]
Sent: Tuesday, July 22, 2003 12:29 PM
To: Josh Berkus; Rod Taylor; Sean Chittenden
Cc: Gavin Sherry; Robert Treat; Postgresql Advocacy
Subject: Re: [pgsql-advocacy] 7.4 Press Release -- Draft #3

On Tuesday 22 July 2003 09:13, Josh Berkus wrote:
> > You can use my name if you like (Rod Taylor with InQuent
Technologies
> > Inc.).
>
"If you tried PostgreSQL before, and it wasn't quite fast enough, and
you
went with Oracle, it's time to re-evaluate," suggests Rod Taylor of
InQuent Technologies. "PostgreSQL should be just as fast, if not faster,
and
it's certainly cheaper."

You might want to change the possesive nature of this quote (WE should
be....), makes it sound like it's PostgreSQL making the claim, not a
user/DBA.


--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx:  250.763.1759
http://www.wavefire.com

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Robert,

> The discussion seemed to be leaning toward contrib rather than gborg,
> has a decision swung the other way?

I'm arguing for contrib, just for the PR appeal.

So, here's my paragraph:

An enhanced and production-tested replication solution developed by PostgreSQL
Inc. of Toronto is included in this release.   "eRServer 1.0" adds a
long-sought higher level of enterprise scalibility to PostgreSQL's Open
Source replication possibilities.

--
Josh Berkus
Aglio Database Solutions
San Francisco

I disagree on both points; I think 'is' is too strong of a word, since
we can't guarantee peoples apps will run faster.

..and it's certainly cheaper.
..and it's cheaper.
..and it's much cheaper.

certainly infers that you already know it's cheaper, the others are just
us telling you it's cheaper.

Robert Treat

On Tue, 2003-07-22 at 12:51, Merlin Moncure wrote:
> I would replace 'should be' with 'is' and remove 'certainly' (or replace
> with much) for a stronger statement...
>
> Regards,
> Merlin
>
>
> -----Original Message-----
> From: Darcy Buskermolen [mailto:darcy@wavefire.com]
> Sent: Tuesday, July 22, 2003 12:29 PM
> To: Josh Berkus; Rod Taylor; Sean Chittenden
> Cc: Gavin Sherry; Robert Treat; Postgresql Advocacy
> Subject: Re: [pgsql-advocacy] 7.4 Press Release -- Draft #3
>
> On Tuesday 22 July 2003 09:13, Josh Berkus wrote:
> > > You can use my name if you like (Rod Taylor with InQuent
> Technologies
> > > Inc.).
> >
> "If you tried PostgreSQL before, and it wasn't quite fast enough, and
> you
> went with Oracle, it's time to re-evaluate," suggests Rod Taylor of
> InQuent Technologies. "PostgreSQL should be just as fast, if not faster,
> and
> it's certainly cheaper."
>
> You might want to change the possesive nature of this quote (WE should
> be....), makes it sound like it's PostgreSQL making the claim, not a
> user/DBA.
>
>
> --
> Darcy Buskermolen
> Wavefire Technologies Corp.
> ph: 250.717.0200
> fx:  250.763.1759
> http://www.wavefire.com
>
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Tue, 2003-07-22 at 12:45, Josh Berkus wrote:
> Also:   I may have a great quote from a Federal Reserve Bank (woo-hoo); I
> waiting on confirmation.
>

"We tried several commercial database solutions but none of them could
keep up with the rate of our ever expanding budget deficit. Thanks to
PostgreSQL, not only does our operation run smoothly, the lower TCO
helps us curb spending too!"


:-)


Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Tue, 22 Jul 2003, Josh Berkus wrote:

> People,
>
> Remember, everyone, this is a Press Release for the **trade press**.  It does
> NOT pay to get too technical.   For example, I'd re-write the below as:
>
> > Improvements to the query planner, including a redesign of subquery
> > handling with the IN() clause, resulting in considerable speed
> > improvements.
>
> Improvements in subquery handling by the planner resulting in up to 400% speed
> increases in some complex queries.
>
> (the 400% is based on a couple of examples on -PERFORMANCE)
>
> Even a trade reporter ... like the Linux Weekly News ... isn't likely to
> understand " IN() subquery".
>
> > > Optional explicit join rewriting by the query planner,
> > > allowing an easy transition for MS SQL Server users.
> >
> > I don't like that, because istm win32 would really make transition
> > easier, and I'd like to avoid bringing up thoughts of that...
>
> Sure it would, but the from_collapse_order was a big deal to several former
> MSSQL DBAs on our lists.
>
> > Are there other databases that use this behavior?
>
> Yes, Sybase.  Not sure about others.  I see where you're going:
>
> Optional explicit join rewriting by the query planner,
> allowing an easy transition for MS SQL Server and Sybase
> users.
>
> > > Mentioning support for AMD's Opteron would also be a good bit to have
> > > since that says, "we're a safe database to base your business around
> > > because we move with the times and support cutting edge hardware, even
> > > though the project has been around forever."
> >
> > still thinking on this one... it's not new that we support 64bit
> > hardware.
>
> No, it's not.  I point out, though, that MySQL got a significant amount of
> press milage out of their support for AIX last year ... even though we've had
> it for 2 years.  Since we *do* have production-tested support for Opteron in
> this release, we need to trumpet it loud and "grab the high ground."

If we're going to say something about opteron / 64bit, we should probably
say something like:

"Version 7.4 now includes support for compiling in 64 bit mode on the AMD
Opteron, this brings the total number of 64 bit systems Postgresql can run
on to (number here) including: (architectures go here)."

That's still awkward, but you get my point, we should mention the other
architectures.  Probably not a bad idea to throw in how long postgesql has
been 64 bit clean as well.

> > Are there other databases that use this behavior?
>
> Yes, Sybase.  Not sure about others.  I see where you're going:
>
> Optional explicit join rewriting by the query planner, allowing an
> easy transition for MS SQL Server and Sybase users.

easing the transition of existing applications and queries running on
MS SQL Server and Sybase.

-sc

--
Sean Chittenden

Scott:

> "Version 7.4 now includes support for compiling in 64 bit mode on the AMD
> Opteron, this brings the total number of 64 bit systems Postgresql can run
> on to (number here) including: (architectures go here)."
>
> That's still awkward, but you get my point, we should mention the other
> architectures.  Probably not a bad idea to throw in how long postgesql has
> been 64 bit clean as well.

Can you find this out?  I like the above text, but I'd like you to fill in the
details.


Sean:

On Tuesday 22 July 2003 10:53, Sean Chittenden wrote:
> > easy transition for MS SQL Server and Sybase users.
>
> easing the transition of existing applications and queries running on
> MS SQL Server and Sybase.

I like this too.


--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

Folks,

> > Also:   I may have a great quote from a Federal Reserve Bank (woo-hoo); I
> > waiting on confirmation.

DENIED!   I didn't think a national quasi-gov't organization would approve
being quoted, and they didn't ....

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

> > > Also: I may have a great quote from a Federal Reserve Bank
> > > (woo-hoo); I waiting on confirmation.
>
> DENIED!  I didn't think a national quasi-gov't organization would
> approve being quoted, and they didn't ....

Alright, then off the record, what'd they say?  -sc

--
Sean Chittenden

Sean,

> Alright, then off the record, what'd they say?  -sc

An employee at one Federal Reserve Bank was very enthusiastic about the new
TSearch features.   However, he does not speak for that FSB or even for his
department, so we can't really use the quote.

Bummer :-(

This is a continuous problem with getting quotes for PostgreSQL.  Lots of
large corporations and gov't agencies use it, but nobody wants to hassle with
their legal department in order to get clearance for a quote.

Mind you, this isn't just us ... proprietary software companies run into the
same thing.  Unlike us, though, they can offer discounts or free services in
exchange for quotability.

Suggestions, anyone?

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

On Tue, 22 Jul 2003, Sean Chittenden wrote:

> > > > Also: I may have a great quote from a Federal Reserve Bank
> > > > (woo-hoo); I waiting on confirmation.
> >
> > DENIED!  I didn't think a national quasi-gov't organization would
> > approve being quoted, and they didn't ....
>
> Alright, then off the record, what'd they say?  -sc

I wonder if we could the Freedom of Information Act to find out.  :-)

It would probably be redacted to say something like:

"[DATABASE1] was the best choice of the bunch, for the following reasons:

It's much faster at [DELETED],
handles sub-[DELETED] much better than [DATABASE2], and provided better
data [DELETED].

The fact that all the [DELETE] is transactionable was one of the major
reasons for choosing [DATABASE1]."

Scott,

> No prob.  It looks like
> HPUX on PA-RISC,
> IRIX on MIPS,
> Linux on S/390,
> Solaris on Sparc, (listed in the /doc/FAQ_Solaris as 64 bit)
> and NetBSD on Sparc are all 64 bit tested / compiled.

I think for simplicity that we should stick to the hardware: e.g.,
Sparc, PA-RISC, MIPS, and S/390. (yes, Sparc is 64-bit).

> AIX on RS6000,
> FreeBSD on Alpha
> Linux on Alpha
> Linux on MIPS
> Linux on Sparc
> NetBSD on MIPS

Also, we should skip these if you can't find evidence of production PostgreSQL
servers on them.   Unless you can and your only question is are they 64-bit?
We are talking about "official" or at least "tested" support.

> Anyone have anymore input on this?  Are there other issues (i.e. we're
> only half 64 bit and half 32 bit in some areas) that we need to make
> clear?

We don't need to make this clear to the press, no.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

Folks,

BTW, does anyone remember the name of the university that did the Opteron
patch?

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

U mass, @ amherst  the astrophysics department.


On Tuesday 22 July 2003 11:38, Josh Berkus wrote:
> Folks,
>
> BTW, does anyone remember the name of the university that did the Opteron
> patch?

--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx:  250.763.1759
http://www.wavefire.com

There is a guy at the St. Louis Federal Reserve that uses PostgreSQL a
lot.  I met him at O'Reilly, and he was there last year too.  His last
name was Malloney.  I think this is the page:

    http://research.stlouisfed.org/fred2/

---------------------------------------------------------------------------

Josh Berkus wrote:
> Sean,
>
> > Alright, then off the record, what'd they say?  -sc
>
> An employee at one Federal Reserve Bank was very enthusiastic about the new
> TSearch features.   However, he does not speak for that FSB or even for his
> department, so we can't really use the quote.
>
> Bummer :-(
>
> This is a continuous problem with getting quotes for PostgreSQL.  Lots of
> large corporations and gov't agencies use it, but nobody wants to hassle with
> their legal department in order to get clearance for a quote.
>
> Mind you, this isn't just us ... proprietary software companies run into the
> same thing.  Unlike us, though, they can offer discounts or free services in
> exchange for quotability.
>
> Suggestions, anyone?
>
> --
> -Josh Berkus
>  Aglio Database Solutions
>  San Francisco
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>

--
  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

Guys,

> There is a guy at the St. Louis Federal Reserve that uses PostgreSQL a
> lot.  I met him at O'Reilly, and he was there last year too.  His last
> name was Malloney.  I think this is the page:

Can we drop this line of discussion?   If we can't quote the FSB in a press
release, discussing them on a public mailing list isn't friendly either.

We're not here to "out" people.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

On Tue, 22 Jul 2003, Josh Berkus wrote:

> Robert,
>
> > The discussion seemed to be leaning toward contrib rather than gborg,
> > has a decision swung the other way?
>
> I'm arguing for contrib, just for the PR appeal.

For the several reasons presented to me so far, I'm swaying towards
contrib as well ... but, after some discussions on our internal devel list
for erserver, we aren't sure how easy that will be ... we ship with
several pre-built jar files, including ant.jar, so that we don't have to
worry about some issues with changes to those files ... the problem is
ant's license ...

we're still discussing how to get around those issues, hope to have
something by the end of the week ...

On Tue, 2003-07-22 at 14:52, Josh Berkus wrote:
> Guys,
>
> > There is a guy at the St. Louis Federal Reserve that uses PostgreSQL a
> > lot.  I met him at O'Reilly, and he was there last year too.  His last
> > name was Malloney.  I think this is the page:
>
> Can we drop this line of discussion?   If we can't quote the FSB in a press
> release, discussing them on a public mailing list isn't friendly either.
>
> We're not here to "out" people.
>

FWIW he has "outed" himself, I think on the -general list. Check the
archives. I seem to recall emailing him a couple times a while back...

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

OK, how about:

"Version 7.4 expands 64 bit support to include the AMD Opteron, in
addition to the 64 bit platforms that Postgresql already supports, which
are: PA-RISC, Sparc, S/390, MIPS, Alpha, and RS6000"

On 22 Jul 2003, Robert Treat wrote:

> On Tue, 2003-07-22 at 14:52, Josh Berkus wrote:
> > Guys,
> >
> > > There is a guy at the St. Louis Federal Reserve that uses PostgreSQL a
> > > lot.  I met him at O'Reilly, and he was there last year too.  His last
> > > name was Malloney.  I think this is the page:
> >
> > Can we drop this line of discussion?   If we can't quote the FSB in a press
> > release, discussing them on a public mailing list isn't friendly either.
> >
> > We're not here to "out" people.
> >
>
> FWIW he has "outed" himself, I think on the -general list. Check the
> archives. I seem to recall emailing him a couple times a while back...

I would think it would be ok to at least point to the site as an example
of a large installation using postgresql without having to quote him or
anything.

On Tue, Jul 22, 2003 at 09:13:34AM -0700, Josh Berkus wrote:
>
> "If you tried PostgreSQL before, and it wasn't quite fast enough,
> and you went with Oracle, it's time to re-evaluate," suggests Rod

Can I suggest you use "something else" instead of "Oracle"?  I know
it's weasely, but Oracle has lawyers and they're not afraid to use
them.

A

----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

On Mon, Jul 21, 2003 at 06:42:09PM -0400, Robert Treat wrote:
>
> A couple of people have asked about this so let me expand on this
> ambiguous note. There a couple of folks, led by Andrew Sullivan, who are
> looking at releasing the replication code first used by Afilias, Inc

I am leaning toward gborg at the moment.  See my recent post on
-hackers.

Note that I Don't Own the Code, PostgreSQL Inc. does.  So they're the
ones leading this and doing it.  I just volunteered to help figure
out what has to change to release it (there's a lot of cruft in the
original source tree, it seems, and it all came from Toronto.  Hmm,
sounds like a horror movie).


> as good as what you would get if you were to purchase the commercial
> version of ERServer (at least that's what I've been told), but it has

The new version really is a quantum leap forward, thanks largely to
some work that my colleague Frank Thompson recently did.  Jan Wieck also
found a bug in part of the older code, and fixed it.  I _think_ that
bug fix will make it into the released code, but I have to check.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

On Tue, 22 Jul 2003 15:34:49 -0400, Andrew Sullivan wrote:
> On Tue, Jul 22, 2003 at 09:13:34AM -0700, Josh Berkus wrote:
> >
> > "If you tried PostgreSQL before, and it wasn't quite fast enough,
> > and you went with Oracle, it's time to re-evaluate," suggests Rod
>
> Can I suggest you use "something else" instead of "Oracle"?  I know
> it's weasely, but Oracle has lawyers and they're not afraid to use
> them.
>

"If you tried PostgreSQL before and went with a commercial solution for speed,
it's time to re-evaluate," suggests...


Robert Treat

--
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

On Tue, 2003-07-22 at 19:34, Andrew Sullivan wrote:
> On Tue, Jul 22, 2003 at 09:13:34AM -0700, Josh Berkus wrote:
> >
> > "If you tried PostgreSQL before, and it wasn't quite fast enough,
> > and you went with Oracle, it's time to re-evaluate," suggests Rod
>
> Can I suggest you use "something else" instead of "Oracle"?  I know
> it's weasely, but Oracle has lawyers and they're not afraid to use
> them.

... and you went with another enterprise level DB, it's time to ....

?

Andrew,

> On Tue, Jul 22, 2003 at 09:13:34AM -0700, Josh Berkus wrote:
> > "If you tried PostgreSQL before, and it wasn't quite fast enough,
> > and you went with Oracle, it's time to re-evaluate," suggests Rod
>
> Can I suggest you use "something else" instead of "Oracle"?  I know
> it's weasely, but Oracle has lawyers and they're not afraid to use
> them.

How could Oracle sue us for claiming to be as good or faster?   MySQL does
this all the time, and I don't see that it's landed them in any legal hot
water.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Tue, 22 Jul 2003, Josh Berkus wrote:

> Andrew,
>
> > On Tue, Jul 22, 2003 at 09:13:34AM -0700, Josh Berkus wrote:
> > > "If you tried PostgreSQL before, and it wasn't quite fast enough,
> > > and you went with Oracle, it's time to re-evaluate," suggests Rod
> >
> > Can I suggest you use "something else" instead of "Oracle"?  I know
> > it's weasely, but Oracle has lawyers and they're not afraid to use
> > them.
>
> How could Oracle sue us for claiming to be as good or faster?   MySQL does
> this all the time, and I don't see that it's landed them in any legal hot
> water.

Its not a fair statement and it is not rigorously proven. As such, I'd go
for a more generalised statement.

Gavin

On Tuesday 22 July 2003 15:20, scott.marlowe wrote:
> OK, how about:
>
> "Version 7.4 expands 64 bit support to include the AMD Opteron, in
> addition to the 64 bit platforms that Postgresql already supports, which
> are: PA-RISC, Sparc, S/390, MIPS, Alpha, and RS6000"
>

A less wordy version:

PostgreSQL 7.4 now supports the AMD Opteron in addition to other 64 bit
platforms including PA-RISC, Sparc, S/390, MIPS, Alpha, and RS6000*

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Wed, Jul 23, 2003 at 12:54:08AM -0400, Robert Treat wrote:
> A less wordy version:
>
> PostgreSQL 7.4 now supports the AMD Opteron in addition to other 64 bit
> platforms including PA-RISC, Sparc, S/390, MIPS, Alpha, and RS6000*
>
> Robert Treat

I disagree with the wording here.. pg does not 'support' these chips, the
kernel of the operating system does.

if we use the term 'support', imho the press might get the wrong idea.

pg has probably been *tested* on those platforms, or it is coded in such a
way that it will work just fine on 64 bit platforms.

just my two cents. :)

regards,
J
--
|| Jeff - http://zoidtechnologies.com/
|| GNUPG Fingerprint: A607 0F19 7C75 1305 67E4  BDFF 26BD 606E 3517 2A42

On Wed, 2003-07-23 at 07:39, Jeff wrote:
> On Wed, Jul 23, 2003 at 12:54:08AM -0400, Robert Treat wrote:
> > A less wordy version:
> >
> > PostgreSQL 7.4 now supports the AMD Opteron in addition to other 64 bit
> > platforms including PA-RISC, Sparc, S/390, MIPS, Alpha, and RS6000*
> >
> > Robert Treat
>
> I disagree with the wording here.. pg does not 'support' these chips, the
> kernel of the operating system does.
>
> if we use the term 'support', imho the press might get the wrong idea.
>
> pg has probably been *tested* on those platforms, or it is coded in such a
> way that it will work just fine on 64 bit platforms.
>
> just my two cents. :)
>
Hmm... do you just dislike the way I used support? Lets flip it to match
the original wording:

PostgreSQL 7.4 expands 64 bit support to include  AMD Opteron in
addition to other 64 bit platforms including PA-RISC, Sparc, S/390,
MIPS, Alpha, and RS6000*

or maybe better is:

PostgreSQL 7.4 expands 64 bit compatibility to include  AMD Opteron in
addition to other 64 bit platforms including PA-RISC, Sparc, S/390,
MIPS, Alpha, and RS6000*


(note to all: I'll be posting a draft #4 sometime tonight)


Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Wed, Jul 23, 2003 at 08:43:05AM -0400, Robert Treat wrote:
> Hmm... do you just dislike the way I used support? Lets flip it to match
> the original wording:
>
> PostgreSQL 7.4 expands 64 bit support to include  AMD Opteron in
> addition to other 64 bit platforms including PA-RISC, Sparc, S/390,
> MIPS, Alpha, and RS6000*
>
> or maybe better is:
>
> PostgreSQL 7.4 expands 64 bit compatibility to include  AMD Opteron in
> addition to other 64 bit platforms including PA-RISC, Sparc, S/390,
> MIPS, Alpha, and RS6000*

*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?

I am sure that, for example, mysql will compile just fine on a 64 bit
platform (given gcc of course), and it may actually run, but that doesn't
mean it has been "tested" or "used in production".. so mysql (oracle, etc)
can claim "64 bit compatibility" just like pg does, and pg doesn't win
anything by using that terminology.

picture this:

reporter: "hi, oracle sales guy: I am doing some research on RDBMS software,
and I am noticing your competitor claims 64 bit compatiblility on x y z new
fangled CPU"

oracle sales guy: "yup! we do that! just pay us!"

etc..

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.

regards,
J
--
|| Jeff - http://zoidtechnologies.com/
|| GNUPG Fingerprint: A607 0F19 7C75 1305 67E4  BDFF 26BD 606E 3517 2A42

On 23 Jul 2003 at 8:43, Robert Treat wrote:
> Hmm... do you just dislike the way I used support? Lets flip it to match
> the original wording:
>
> PostgreSQL 7.4 expands 64 bit support to include  AMD Opteron in
> addition to other 64 bit platforms including PA-RISC, Sparc, S/390,
> MIPS, Alpha, and RS6000*
>
> or maybe better is:
>
> PostgreSQL 7.4 expands 64 bit compatibility to include  AMD Opteron in
> addition to other 64 bit platforms including PA-RISC, Sparc, S/390,
> MIPS, Alpha, and RS6000*

How about postgresql is capable of taking advantage of 64bit hardware
architecture? I mean if it can make work with 4GB dataset just like that, it
will say lot better than a vague "support"

Just a thought..

Bye
 Shridhar

--
"[In 'Doctor' mode], I spent a good ten minutes telling Emacs what Ithought of
it.  (The response was, 'Perhaps you could try to be lessabusive.')"(By Matt
Welsh)

On 23 Jul 2003 at 10:08, Jeff wrote:

> I am sure that, for example, mysql will compile just fine on a 64 bit
> platform (given gcc of course), and it may actually run, but that doesn't
> mean it has been "tested" or "used in production".. so mysql (oracle, etc)
> can claim "64 bit compatibility" just like pg does, and pg doesn't win
> anything by using that terminology.

If mysql works on 64 bit platform, is it able to take advantage of 64bits? Is
it 64 bit clean, in sense of ILP paradigm?

Bye
 Shridhar

--
First Law of Bicycling:    No matter which way you ride, it's uphill and against the wind.

On Tue, Jul 22, 2003 at 04:18:24PM -0700, Josh Berkus wrote:

> How could Oracle sue us for claiming to be as good or faster?   MySQL does
> this all the time, and I don't see that it's landed them in any legal hot
> water.

Call me nervous.

I believe the rule that Oracle has is that you cannot publish
benchmarks of their system without their approval.  Doing so violates
your license to use the software.  So, either you cannot claim the
"faster" result on the grounds that you have no basis for the claim;
or, you're violating your license with Oracle.  So, even if Oracle
has no interest in calling out their counsel, it's still a bad idea
to mention them explicitly, because it makes the claims in the
release either goundless or license-violating.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

> I believe the rule that Oracle has is that you cannot publish
> benchmarks of their system without their approval.  Doing so violates
> your license to use the software.  So, either you cannot claim the
> "faster" result on the grounds that you have no basis for the claim;
> or, you're violating your license with Oracle.  So, even if Oracle
> has no interest in calling out their counsel, it's still a bad idea
> to mention them explicitly, because it makes the claims in the
> release either goundless or license-violating.

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."

That lets us grab the press's attention with a mention of competing with
Oracle and DB2 (which I guarentee you will generate at least one headline)
without making specific claims we can't defend without legal counsel.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Wed, Jul 23, 2003 at 11:05:06AM -0700, Josh Berkus wrote:
> That lets us grab the press's attention with a mention of competing with
> Oracle and DB2 (which I guarentee you will generate at least one headline)
> without making specific claims we can't defend without legal counsel.

Yes, I think that's much better.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

How about using the phrase "Optimized for AMD Opteron".  NOTE: You may
be required to get PostgreSQL to pass a standards test to be able to
claim that, but if the test were done it would be a big selling point.


It would be worthwhile to take a look at some software packaging that
does similar things - like software that's "Optimized for Windows."
It's a marketing tool, so you don't have to get too caught up into the
technical jargon.  You simply tell the customer that "part of the
application takes advantage of the powerful features of the AMD
Opteron."

Not sure what that means in terms of actual code written - anyone have
that information?

Richard Schilling


On 2003.07.23 05:43 Robert Treat wrote:
> On Wed, 2003-07-23 at 07:39, Jeff wrote:
> > On Wed, Jul 23, 2003 at 12:54:08AM -0400, Robert Treat wrote:
> > > A less wordy version:
> > >
> > > PostgreSQL 7.4 now supports the AMD Opteron in addition to other
> 64 bit
> > > platforms including PA-RISC, Sparc, S/390, MIPS, Alpha, and
> RS6000*
> > >
> > > Robert Treat
> >
> > I disagree with the wording here.. pg does not 'support' these
> chips, the
> > kernel of the operating system does.
> >
> > if we use the term 'support', imho the press might get the wrong
> idea.
> >
> > pg has probably been *tested* on those platforms, or it is coded in
> such a
> > way that it will work just fine on 64 bit platforms.
> >
> > just my two cents. :)
> >
> Hmm... do you just dislike the way I used support? Lets flip it to
> match
> the original wording:
>
> PostgreSQL 7.4 expands 64 bit support to include  AMD Opteron in
> addition to other 64 bit platforms including PA-RISC, Sparc, S/390,
> MIPS, Alpha, and RS6000*
>
> or maybe better is:
>
> PostgreSQL 7.4 expands 64 bit compatibility to include  AMD Opteron in
> addition to other 64 bit platforms including PA-RISC, Sparc, S/390,
> MIPS, Alpha, and RS6000*
>
>
> (note to all: I'll be posting a draft #4 sometime tonight)
>
>
> Robert Treat
> --
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo@postgresql.org
>

Richard Schilling wrote:
> How about using the phrase "Optimized for AMD Opteron".  NOTE: You
> may be required to get PostgreSQL to pass a standards test to be
> able to claim that, but if the test were done it would be a big
> selling point.

It doesn't strike me as being a claim that is meaningfully true.

What would be accurate, meaningful, and actually somewhat descriptive
would be:

"Takes full advantage of large (>2GB) memory configurations on
numerous 64 bit platforms including AMD Opteron, HP/Compaq Alpha,
Intel IA-64, Sun UltraSPARC, MIPS, [blah, blah, blah, others...]"
--
select 'cbbrowne' || '@' || 'libertyrms.info';
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)

On Wed, Jul 23, 2003 at 06:43:03PM -0400, Christopher Browne wrote:
> Intel IA-64, Sun UltraSPARC, MIPS, [blah, blah, blah, others...]"
                                      ^^^^^^^^^^^^^^^
I think Josh is right about wanting things to be punchy.  Too much
detail makes for a lousy press release, irrespective of how much
truer it makes the statements.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110