Thread: Time to start the PR machine

Well, folks,  it's that time of year again!  That time when we spend a few
weeks arguing over phrasing in the PostgreSQL Release.

So, here's starting it off (get your word-axes ready):
(oh, and this is the same exact layout as previous releases.  innovative
ideas for re-arranging the text are very welcome)

=================
## November 2005:  The PostgreSQL Global Development Group announced today
the release of PostgreSQL 8.1.   The new version, containing many advanced
database features as well as performance enhancements, makes PostgreSQL
the reference platform for high-volume, high-peformance open source data
centers.

"This is our second major release in 2005," said _____, PostgreSQL major
contributor, "It's very exciting.  Thanks to all of the new programmers
and companies contributing to the project, as well as automated testing,
development is faster than every before."

Among the many enhancements to PostgreSQL 8.1 are:

Improved Multiprocessor (SMP) Performance:  the buffer manager for 8.1 has
been enhanced to scale almost linearly with the number of processors,
leading to significant performance gains on 8-way, 16-way and multicore
servers.

Two-Phase Commit (2PC): long in demand for WAN applications and
heterogenous data centers using PostgreSQL, this feature allows
ACID-compliant transactions across widely separated servers.

Bitmapscan:  Some indexes will be automatically converted to bitmaps in
memory, giving up to 20x faster index performance on complex queries
against very large tables.  Bitmapscan also greatly reduces the need for
multi-column indexes.

Roles:  PostgreSQL now supports database roles, which simplify the
management of large user bases with complex overlapping database rights.

Shared Row Locking:  we have continued to improve on the "better than
row-level locking" which Multi-version Concurrency Control (MVCC) provides
by supporting shared locks for relational references.

Table Partitioning: in version 8.1, the query planner's ability to select
the correct table partitions for each query (called Constraint Exclusion)
is expanded, making PostgreSQL's table partitioning useful to a broader
range of applications.

"Blah new features blah blah," remarked some high-profile postgresql
contributor. "Blah coolest yet blah blah blah."

There are numerous other enhancements, which are detailed on our 8.1
release page <link here>.

Thanks to automated testing by a variety of sources, the PostgreSQL
community has been able to have a shorter-than-ever beta period while
increasing the reliability of the code.   This included Andrew Dunstan's
pgbuildfarm, OSDL's Scalable Test Platform, SpikeSource's SpikeWatch, and
Coverity Prevent.   As any developer knows, bugs caught early take far
less time to resolve, and these tools have made that adage a reality for
PostgreSQL.

<contact info>

<about postgresql>


--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On 8/26/05, Josh Berkus <josh@agliodbs.com> wrote:
> ## November 2005:  The PostgreSQL Global Development Group announced today
> the release of PostgreSQL 8.1.   The new version, containing many advanced
> database features as well as performance enhancements, makes PostgreSQL
> the reference platform for high-volume, high-peformance open source data
> centers.

"... continues PostgreSQL position as the reference platform..."

Never admit you weren't the best.  It's silly, and it's all marketing
fluff, but it's about positioning the product as the best, and as
something that has been the best for a while.

> "This is our second major release in 2005," said _____, PostgreSQL major
> contributor, "It's very exciting.  Thanks to all of the new programmers
> and companies contributing to the project, as well as automated testing,
> development is faster than every before."

"... development is faster than ever before, without sacrificing the
stability and quality-control that PostgreSQL is known for."

> Bitmapscan:  Some indexes will be automatically converted to bitmaps in
> memory, giving up to 20x faster index performance on complex queries
> against very large tables.  Bitmapscan also greatly reduces the need for
> multi-column indexes.

"... against very large tables, such as those found in data marts and
data warehousing applications."

> Shared Row Locking:  we have continued to improve on the "better than
> row-level locking" which Multi-version Concurrency Control (MVCC) provides
> by supporting shared locks for relational references.

Can we give an example of how this increases performance, or reduces
deadlock opportunities?  I'm not sure how to explain this to the
"average DBA," who sometimes misses the point of MVCC.

> Table Partitioning: in version 8.1, the query planner's ability to select
> the correct table partitions for each query (called Constraint Exclusion)
> is expanded, making PostgreSQL's table partitioning useful to a broader
> range of applications.

I'd move this up near bitmap indexing, and play the two together, as
they're really big deals for data mart and data warehousing
applications.  Somehow tying the two together would be useful, I
think.

> "Blah new features blah blah," remarked some high-profile postgresql
> contributor. "Blah coolest yet blah blah blah."

Needs more foo, less bar.

Great work, as always.

Chris
--
| Christopher Petrilli
| petrilli@gmail.com

Very nice first shot. I think you are getting the hang
of this :)

My suggestion overall is to identify the ones where
"magic" just happens and the one you have to do something
to use.  It seems that the ones that just improve overall
are strong this time with bitmap indexes and improved
multiprocessor performance.

--elein

On Fri, Aug 26, 2005 at 02:05:48PM -0700, Josh Berkus wrote:
> Well, folks,  it's that time of year again!  That time when we spend a few
> weeks arguing over phrasing in the PostgreSQL Release.
>
> So, here's starting it off (get your word-axes ready):
> (oh, and this is the same exact layout as previous releases.  innovative
> ideas for re-arranging the text are very welcome)
>
> =================
> ## November 2005:  The PostgreSQL Global Development Group announced today
> the release of PostgreSQL 8.1.   The new version, containing many advanced
> database features as well as performance enhancements, makes PostgreSQL
> the reference platform for high-volume, high-peformance open source data
> centers.
>
> "This is our second major release in 2005," said _____, PostgreSQL major
> contributor, "It's very exciting.  Thanks to all of the new programmers
> and companies contributing to the project, as well as automated testing,
> development is faster than every before."
>
> Among the many enhancements to PostgreSQL 8.1 are:
>
> Improved Multiprocessor (SMP) Performance:  the buffer manager for 8.1 has
> been enhanced to scale almost linearly with the number of processors,
> leading to significant performance gains on 8-way, 16-way and multicore
> servers.
>
> Two-Phase Commit (2PC): long in demand for WAN applications and
> heterogenous data centers using PostgreSQL, this feature allows
> ACID-compliant transactions across widely separated servers.
>
> Bitmapscan:  Some indexes will be automatically converted to bitmaps in
> memory, giving up to 20x faster index performance on complex queries
> against very large tables.  Bitmapscan also greatly reduces the need for
> multi-column indexes.
>
> Roles:  PostgreSQL now supports database roles, which simplify the
> management of large user bases with complex overlapping database rights.
>
> Shared Row Locking:  we have continued to improve on the "better than
> row-level locking" which Multi-version Concurrency Control (MVCC) provides
> by supporting shared locks for relational references.
>
> Table Partitioning: in version 8.1, the query planner's ability to select
> the correct table partitions for each query (called Constraint Exclusion)
> is expanded, making PostgreSQL's table partitioning useful to a broader
> range of applications.
>
> "Blah new features blah blah," remarked some high-profile postgresql
> contributor. "Blah coolest yet blah blah blah."
>
> There are numerous other enhancements, which are detailed on our 8.1
> release page <link here>.
>
> Thanks to automated testing by a variety of sources, the PostgreSQL
> community has been able to have a shorter-than-ever beta period while
> increasing the reliability of the code.   This included Andrew Dunstan's
> pgbuildfarm, OSDL's Scalable Test Platform, SpikeSource's SpikeWatch, and
> Coverity Prevent.   As any developer knows, bugs caught early take far
> less time to resolve, and these tools have made that adage a reality for
> PostgreSQL.
>
> <contact info>
>
> <about postgresql>
>
>
> --
> --Josh
>
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

elein@varlena.com (elein) writes:
> Very nice first shot. I think you are getting the hang
> of this :)
>
> My suggestion overall is to identify the ones where
> "magic" just happens and the one you have to do something
> to use.  It seems that the ones that just improve overall
> are strong this time with bitmap indexes and improved
> multiprocessor performance.

Speaking of bitmap indexes, let's keep in the queue somewhere the fact
that updates should go into the following Wikipedia page once 8.1 is
released...

<http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems>

There may be something to be added vis-a-vis table partitioning; the
table indicates that isn't supported, but I'm not sure that's entirely
true...
--
let name="cbbrowne" and tld="ntlug.org" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/linuxdistributions.html
"Sigh.  I like to  think it's just the Linux people who  want to be on
the `leading edge' so bad they walk right off the precipice."
-- Craig E. Groeschel

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


Okay, here is my first pass. I've got more comments that what I've said here,
but we'll start out easy. ;)

> ## November 2005:  The PostgreSQL Global Development Group announced today

What, no byline to argue over? Gainesville, FL okay with everyone? :)

s/announced today/announces/? or simply "announced"? "has announced"?
(I'm not liking the "today" part, obviously)

> the release of PostgreSQL 8.1.   The new version, containing many advanced
> database features as well as performance enhancements, makes PostgreSQL

Might be nice to have a few words about what PostgreSQL is: we don't say
anywhere that we are a RDBMS, that we are BSD-licensed, and that we are
the most powerful (open source) db.

> the reference platform for high-volume, high-peformance open source data
> centers.

s/peformance/performance/

Are we a "platform?" Is there a better word?

Do we need "open source" in that sentence?

> "This is our second major release in 2005," said _____, PostgreSQL major
> contributor, "It's very exciting.  Thanks to all of the new programmers
> and companies contributing to the project, as well as automated testing,
> development is faster than every before."

'This is the second major release' may sound better. (s/our/the/)

The second sentence is awkward. Put the main part first: "Development is
faster than ever, thanks to ...." Or it could stay. I'm not strong on this one.

> Among the many enhancements to PostgreSQL 8.1 are:

> Improved Multiprocessor (SMP) Performance:  the buffer manager for 8.1 has
> been enhanced to scale almost linearly with the number of processors,
> leading to significant performance gains on 8-way, 16-way and multicore
> servers.

Need a comma after "16-way"

Is "multicore" a commonly used word? We might want to tone down the technical
feel of the whole release a bit.

"has been enhanced" is too much of a passive voice, perhaps we can say something like
"..manager for 8.1 now scales almost linearly"

I'd put the word "CPU" in there somehow. Non-technical people will recognize
that more than SMP and "8-way"

> Two-Phase Commit (2PC): long in demand for WAN applications and
> heterogenous data centers using PostgreSQL, this feature allows
> ACID-compliant transactions across widely separated servers.

s/heterogenous/heterogeneous/

Insert "to be run" before "across"

> Bitmapscan:  Some indexes will be automatically converted to bitmaps in
> memory, giving up to 20x faster index performance on complex queries
> against very large tables.  Bitmapscan also greatly reduces the need for
> multi-column indexes.

I think bitmapscan should be two words, not one? And plural?

"will be" not quite right in lead sentence, change to "are now automatically converted"

s/20x/twenty times/

Is the above 20x figure backed up with data somewhere?

> Roles:  PostgreSQL now supports database roles, which simplify the
> management of large user bases with complex overlapping database rights.

Can we say "fully supports"? If we do, we should.

s/user bases/numbers of users/

> Shared Row Locking:  we have continued to improve on the "better than
> row-level locking" which Multi-version Concurrency Control (MVCC) provides
> by supporting shared locks for relational references.

This is the only place we use "we": consider making PG the subject.

s/shared locks/shared row locks/

Comma needed after "provides" so it doesn't read as "MVCC provides by" and
links "supporting" to "MVCC"

> Table Partitioning: in version 8.1, the query planner's ability to select
> the correct table partitions for each query (called Constraint Exclusion)
> is expanded, making PostgreSQL's table partitioning useful to a broader
> range of applications.

Do we need to give the technical name in parens? We're not really going
into details for any of these items, after all.

I'd move this item up higher on the list. 2PC up higher too.

> "Blah new features blah blah," remarked some high-profile postgresql
> contributor. "Blah coolest yet blah blah blah."

> There are numerous other enhancements, which are detailed on our 8.1
> release page <link here>.

s/our/the/

> Thanks to automated testing by a variety of sources, the PostgreSQL
> community has been able to have a shorter-than-ever beta period while
> increasing the reliability of the code.   This included Andrew Dunstan's
> pgbuildfarm, OSDL's Scalable Test Platform, SpikeSource's SpikeWatch, and
> Coverity Prevent.   As any developer knows, bugs caught early take far
> less time to resolve, and these tools have made that adage a reality for
> PostgreSQL.

"As any developer knows" is odd for a press release.

Replace "shorter-than-ever" with "has managed to significantly reduce the beta testing period."

s/Coverity Prevent/the Coverity Prevent tool/


Other stuff:

Mention something about the success of the Win32 version, e.g. how this is the second
major version with Win32, lots of downloads, no problems, everyone happy, etc.

Mention "hundreds of developers" as in the past?

Mention any companies by name?

Mention our high score in that bug-finder thing?

Mention the new options available (bizgres, enterprisedb, etc.) even if only generically?

Emphasize the freedom of the BDS license?

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200508281146
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFDEdxmvJuQZxSWSsgRAqbkAKC5CG9oRro6MxnDADrRAA9S9DzYtQCgv3Mh
SriAhUj5m0sVvWiLFHTIR2Q=
=1VeQ
-----END PGP SIGNATURE-----

You should set it up as a wiki where everyone can tweak it :D

Josh Berkus wrote:
> Well, folks,  it's that time of year again!  That time when we spend a few
> weeks arguing over phrasing in the PostgreSQL Release.
>
> So, here's starting it off (get your word-axes ready):
> (oh, and this is the same exact layout as previous releases.  innovative
> ideas for re-arranging the text are very welcome)
>
> =================
> ## November 2005:  The PostgreSQL Global Development Group announced today
> the release of PostgreSQL 8.1.   The new version, containing many advanced
> database features as well as performance enhancements, makes PostgreSQL
> the reference platform for high-volume, high-peformance open source data
> centers.
>
> "This is our second major release in 2005," said _____, PostgreSQL major
> contributor, "It's very exciting.  Thanks to all of the new programmers
> and companies contributing to the project, as well as automated testing,
> development is faster than every before."
>
> Among the many enhancements to PostgreSQL 8.1 are:
>
> Improved Multiprocessor (SMP) Performance:  the buffer manager for 8.1 has
> been enhanced to scale almost linearly with the number of processors,
> leading to significant performance gains on 8-way, 16-way and multicore
> servers.
>
> Two-Phase Commit (2PC): long in demand for WAN applications and
> heterogenous data centers using PostgreSQL, this feature allows
> ACID-compliant transactions across widely separated servers.
>
> Bitmapscan:  Some indexes will be automatically converted to bitmaps in
> memory, giving up to 20x faster index performance on complex queries
> against very large tables.  Bitmapscan also greatly reduces the need for
> multi-column indexes.
>
> Roles:  PostgreSQL now supports database roles, which simplify the
> management of large user bases with complex overlapping database rights.
>
> Shared Row Locking:  we have continued to improve on the "better than
> row-level locking" which Multi-version Concurrency Control (MVCC) provides
> by supporting shared locks for relational references.
>
> Table Partitioning: in version 8.1, the query planner's ability to select
> the correct table partitions for each query (called Constraint Exclusion)
> is expanded, making PostgreSQL's table partitioning useful to a broader
> range of applications.
>
> "Blah new features blah blah," remarked some high-profile postgresql
> contributor. "Blah coolest yet blah blah blah."
>
> There are numerous other enhancements, which are detailed on our 8.1
> release page <link here>.
>
> Thanks to automated testing by a variety of sources, the PostgreSQL
> community has been able to have a shorter-than-ever beta period while
> increasing the reliability of the code.   This included Andrew Dunstan's
> pgbuildfarm, OSDL's Scalable Test Platform, SpikeSource's SpikeWatch, and
> Coverity Prevent.   As any developer knows, bugs caught early take far
> less time to resolve, and these tools have made that adage a reality for
> PostgreSQL.
>
> <contact info>
>
> <about postgresql>
>
>

Josh wrote:
> Well, folks,  it's that time of year again!  That time when we spend a
few
> weeks arguing over phrasing in the PostgreSQL Release.
>
> So, here's starting it off (get your word-axes ready):
> (oh, and this is the same exact layout as previous releases.
innovative
> ideas for re-arranging the text are very welcome)
>
> Improved Multiprocessor (SMP) Performance:  the buffer manager for 8.1
has
> been enhanced to scale almost linearly with the number of processors,
> leading to significant performance gains on 8-way, 16-way and
multicore
> servers.

FWIW I am seeing a huge performance increase pretty much across the
board, both in my single proc development server and the dual proc
Opteron production servers.  More specifically, I'm seeing around 20%
reduction in run times for simple queries and an additional 20%
reduction in cpu load, for a staggering 20-40% improvement in server
load characteristics with nary a .conf setting change.

Merlin

On Fri, 2005-08-26 at 14:05 -0700, Josh Berkus wrote:
> Well, folks,  it's that time of year again!  That time when we spend a few
> weeks arguing over phrasing in the PostgreSQL Release.

I'd like to suggest doing 2 press releases:

1. Wide press release showing the coverity results, and saying that 8.1
has just entered beta. Soon.

2. Release notice later in the year.

My experience last year was that the press are interested more in News
or an angle (i.e. #1) and not very interested in software releases (i.e.
#2). I think we *have* to do #2, however...

Best Regards, Simon Riggs

Folks,

> > 1. Wide press release showing the coverity results, and saying that
> > 8.1 has just entered beta. Soon.
> >
> > 2. Release notice later in the year.

This does seem like a good idea.   I know that Coverity wanted to do
something about their results anyway.

I'll work on it and bring something back.

So, if we're cutting that out of the press release, can someone draft me a
paragraph about "other nifty stuff" for the end of the 8.1 PR?  Or maybe
we should focus more on the performance improvements?

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Have we alerted the press about the number of 8.0.x downloads?  That is the most newsworthy item over the past 6
months. 
 

-----Original Message-----
From: Josh Berkus [mailto:josh@agliodbs.com]
Sent: Tuesday, August 30, 2005 2:56 PM
To: pgsql-advocacy@postgresql.org
Cc: Dawid Kuroczko; Simon Riggs
Subject: Re: [pgsql-advocacy] Time to start the PR machine


Folks,

> > 1. Wide press release showing the coverity results, and saying that
> > 8.1 has just entered beta. Soon.
> >
> > 2. Release notice later in the year.

This does seem like a good idea.   I know that Coverity wanted to do 
something about their results anyway.   

I'll work on it and bring something back.

So, if we're cutting that out of the press release, can someone draft me a 
paragraph about "other nifty stuff" for the end of the 8.1 PR?  Or maybe 
we should focus more on the performance improvements?

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Lance,

> Have we alerted the press about the number of 8.0.x downloads?  That is
> the most newsworthy item over the past 6 months.

Hmmm, you're thinking, include something about "over 1 million downloads"
in the 8.1 release?   I like that.

--Josh

--
__Aglio Database Solutions_______________
Josh Berkus               Consultant
josh@agliodbs.com     www.agliodbs.com
Ph: 415-752-2500    Fax: 415-752-2387
2166 Hayes Suite 200    San Francisco, CA

Not just a raw number, but a comparison to 7.x numbers (even if estimated).  

"PostgreSQL 8.0 enjoys growing user interest, generating over 1 million downloads in 6 months.  This compares with
300,000over the first six months of the prior release, demonstrating the project's acceleration in the minds of
databaseusers."
 

-----Original Message-----
From: Josh Berkus [mailto:josh@agliodbs.com]
Sent: Tuesday, August 30, 2005 3:32 PM
To: pgsql-advocacy@postgresql.org
Cc: Lance Obermeyer
Subject: Re: [pgsql-advocacy] Time to start the PR machine


Lance,

> Have we alerted the press about the number of 8.0.x downloads?  That is
> the most newsworthy item over the past 6 months.

Hmmm, you're thinking, include something about "over 1 million downloads" 
in the 8.1 release?   I like that.

--Josh

-- 
__Aglio Database Solutions_______________
Josh Berkus               Consultant
josh@agliodbs.com     www.agliodbs.com
Ph: 415-752-2500    Fax: 415-752-2387
2166 Hayes Suite 200    San Francisco, CA

Lance,

> Not just a raw number, but a comparison to 7.x numbers (even if
> estimated).
>
> "PostgreSQL 8.0 enjoys growing user interest, generating over 1 million
> downloads in 6 months.  This compares with 300,000 over the first six
> months of the prior release, demonstrating the project's acceleration in
> the minds of database users."

Unfortunately, we don't have anything approaching a good estimate of 7.4
downloads.   :-(  Bascially, we have bittorrent numbers, and numbers from
the main FTP server -- and those only for the month of release.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On August 30, 2005 04:50 pm, Josh Berkus wrote:
> > "PostgreSQL 8.0 enjoys growing user interest, generating over 1 million
> > downloads in 6 months.  This compares with 300,000 over the first six
> > months of the prior release, demonstrating the project's acceleration in
> > the minds of database users."
>
> Unfortunately, we don't have anything approaching a good estimate of 7.4
> downloads.   :-(  Bascially, we have bittorrent numbers, and numbers from
> the main FTP server -- and those only for the month of release.

Don't we keep syslog records for all connections?

Robert,

> Don't we keep syslog records for all connections?

Nope, not until December 2004.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Oh, so we can, with a reasonably straight face, say something like this.  "This 1m downloads over the last six months
comparesto the last month of 7.4, which had <x> downloads.
 

-----Original Message-----
From: Josh Berkus [mailto:josh@agliodbs.com]
Sent: Tuesday, August 30, 2005 5:33 PM
To: pgsql-advocacy@postgresql.org
Cc: Robert Bernier
Subject: Re: [pgsql-advocacy] Time to start the PR machine


Robert,

> Don't we keep syslog records for all connections?

Nope, not until December 2004.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

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

Lance Obermeyer wrote:
> Oh, so we can, with a reasonably straight face, say something like
> this.  "This 1m downloads over the last six months compares to the
> last month of 7.4, which had <x> downloads.

If we had historical logs, which I gather we might not, we could make
claims that a certain release was downloaded N times more often than
another one, which would be an interesting number.  But giving out
absolute numbers is just laughable, considering the mirror network, the
redistributors, their mirror networks, and a host of other factors that
make the absolute download numbers from the primary FTP server
completely out of proportion with reality.  I would guess that we have
at least 100 times more installations than downloads from the primary
FTP server, factoring out that not every download leads to a unique
installation.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Tue, 30 Aug 2005, Josh Berkus wrote:

> Lance,
>
>> Not just a raw number, but a comparison to 7.x numbers (even if
>> estimated).
>>
>> "PostgreSQL 8.0 enjoys growing user interest, generating over 1 million
>> downloads in 6 months.  This compares with 300,000 over the first six
>> months of the prior release, demonstrating the project's acceleration in
>> the minds of database users."
>
> Unfortunately, we don't have anything approaching a good estimate of 7.4
> downloads.   :-(  Bascially, we have bittorrent numbers, and numbers from
> the main FTP server -- and those only for the month of release.

Umm, I can give you logs on ftp.postgresql.org going back to Apr 12th of
2004, if that will help any?  Nope, 7.4 was released Nov 16th of 2003 ...
oh, looks like I can give back to Jun 4th 2003, since the xferlog on
developer.postgresql.org (where ftp.postgresql.org used to point) goes
back that far ... might help gets some half-decent estimations?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

marc,

> Umm, I can give you logs on ftp.postgresql.org going back to Apr 12th of
> 2004, if that will help any?  Nope, 7.4 was released Nov 16th of 2003
> ... oh, looks like I can give back to Jun 4th 2003, since the xferlog on
> developer.postgresql.org (where ftp.postgresql.org used to point) goes
> back that far ... might help gets some half-decent estimations?

Hmmm ... actually, that would help.  We could compare the current downloads
from ftp.postgresql.org against the ones from last year and thus get an
estimate of 7.4 downloads.

Can you put them somewhere I can SCP them?   Like on the pgfoundry server
for example?

--Josh

--
__Aglio Database Solutions_______________
Josh Berkus               Consultant
josh@agliodbs.com     www.agliodbs.com
Ph: 415-752-2500    Fax: 415-752-2387
2166 Hayes Suite 200    San Francisco, CA

Josh,

> "Blah new features blah blah," remarked some high-profile postgresql
> contributor. "Blah coolest yet blah blah blah."

Plus, the huge memory (over 2gigs) support on 64bit boxes should be added.

It would be very attractive for some enterprise users.
--
NAGAYASU Satoshi <snaga@snaga.org>

Satoshi,

> Plus, the huge memory (over 2gigs) support on 64bit boxes should be added.
>
> It would be very attractive for some enterprise users.

<grin> a little tooting your own horn?

I've not been able to test (yet) that high amounts of shared_buffers actually
*do* anything useful.   Now, when we get 64-bit *sort* mem ...

--
Josh Berkus
Aglio Database Solutions
San Francisco

Satoshi,

> <grin> a little tooting your own horn?
>
> I've not been able to test (yet) that high amounts of shared_buffers
> actually *do* anything useful.   Now, when we get 64-bit *sort* mem ...

Sorry, that was a little too offhand.  What I meant is that only features
which show some real functionality, buzzword-compliance or major performance
increase are going to make the "short list" for the main press release.
Other features (and there are a lot of them, some of which I personally like
more than the big name features) go on the extended list on the web page.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Merlin,

> FWIW I am seeing a huge performance increase pretty much across the
> board, both in my single proc development server and the dual proc
> Opteron production servers.  More specifically, I'm seeing around 20%
> reduction in run times for simple queries and an additional 20%
> reduction in cpu load, for a staggering 20-40% improvement in server
> load characteristics with nary a .conf setting change.

I'd love to use this quote.   Do you have a title?

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

> Merlin,
>
> > FWIW I am seeing a huge performance increase pretty much across the
> > board, both in my single proc development server and the dual proc
> > Opteron production servers.  More specifically, I'm seeing around 20%
> > reduction in run times for simple queries and an additional 20%
> > reduction in cpu load, for a staggering 20-40% improvement in server
> > load characteristics with nary a .conf setting change.
>
> I'd love to use this quote.   Do you have a title?
>
> --
> --Josh

Database Administrator.  I will get approval plus more advocacy related information ASAP (today).

Many thanks,
Merlin

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


While I recognize that not everyone might agree with all of my previous
suggestions, at least fix the spelling error I pointed out! :)

Here's an edited version of my last message:

> the release of PostgreSQL 8.1.   The new version, containing many advanced
> database features as well as performance enhancements, makes PostgreSQL

Might be nice to have a few words about what PostgreSQL is: we don't say
anywhere that we are a RDBMS, that we are BSD-licensed, and that we are
the most powerful (open source) db. At the very very least, add RDBMS.

> Improved Multiprocessor (SMP) Performance:  the buffer manager for 8.1 has
> been enhanced to scale almost linearly with the number of processors,
> leading to significant performance gains on 8-way, 16-way and multicore
> servers.

Need a comma after "16-way"

Is "multicore" a commonly used word? We might want to tone down the technical
feel of the whole release a bit.

"has been enhanced" is too much of a passive voice, perhaps we can say something like
"..manager for 8.1 now scales almost linearly"

I'd put the word "CPU" in there somehow. Non-technical people will recognize
that more than SMP and "8-way"

> Two-Phase Commit (2PC): long in demand for WAN applications and
> heterogenous data centers using PostgreSQL, this feature allows
> ACID-compliant transactions across widely separated servers.

<*COUGH* HERE IT IS! (four "e"s) />

s/heterogenous/heterogeneous/

Insert "to be run" before "across"

> Bitmapscan:  Some indexes will be automatically converted to bitmaps in
> memory, giving up to 20x faster index performance on complex queries
> against very large tables.  Bitmapscan also greatly reduces the need for
> multi-column indexes.

I think bitmapscan should be two words, not one? And plural?

"will be" not quite right in lead sentence, change to "are now automatically converted"

s/20x/twenty times/

Is the above 20x figure backed up with data somewhere?

> Roles:  PostgreSQL now supports database roles, which simplify
> the management of large user bases with complex overlapping
> database rights.

s/user bases/numbers of users/

> Shared Row Locking: PostgreSQL's "better than row-level
> locking" has been improved further through the addition of
> shared row locks for foreign keys.  Shared locks will improve
> insert and update performance on some OLTP applications.

s/shared locks/shared row locks/

> Table Partitioning: in version 8.1, the query planner's ability to select
> the correct table partitions for each query (called Constraint Exclusion)
> is expanded, making PostgreSQL's table partitioning useful to a broader
> range of applications.

Do we need to give the technical name in parens? We're not really going
into details for any of these items, after all.

I'd move this item up higher on the list.

> There are numerous other enhancements, which are detailed on our 8.1
> release page <link here>.

s/our/the/

Other stuff:

Mention something about the success of the Win32 version, e.g. how this is the second
major version with Win32, lots of downloads, no problems, everyone happy, etc.

Mention "hundreds of developers" as in the past?

Mention any companies by name?

Mention our high score in that bug-finder thing?

Mention the new options available (bizgres, enterprisedb, etc.) even if only generically?

Emphasize the freedom of the BSD license?

Anyone reading this far? :)

Thanks,

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200509191535
https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkMvFN8ACgkQvJuQZxSWSsjA9wCbBStKNm3WgbfI4G4Z6EFfU4jd
+qEAoN0F9Q7vD4hYrwpT7iOJnFlYAUYE
=h6XO
-----END PGP SIGNATURE-----

Greg,

> While I recognize that not everyone might agree with all of my previous
> suggestions, at least fix the spelling error I pointed out! :)

I thought I'd implemented *all* of your suggestions.  Please copy-edit
again.  Are you registered for the Press project on pgfoundry?  You could
make these edits through CVS instead of e-mailing me.

> Here's an edited version of my last message:
> > the release of PostgreSQL 8.1.   The new version, containing many
> > advanced database features as well as performance enhancements, makes
> > PostgreSQL
>
> Might be nice to have a few words about what PostgreSQL is: we don't say
> anywhere that we are a RDBMS, that we are BSD-licensed, and that we are
> the most powerful (open source) db. At the very very least, add RDBMS.

Thank you, I knew the first P needed another sentence.

> > Improved Multiprocessor (SMP) Performance:  the buffer manager for 8.1
> > has been enhanced to scale almost linearly with the number of
> > processors, leading to significant performance gains on 8-way, 16-way
> > and multicore servers.
>
> Need a comma after "16-way"

Actually, that's a style thing.   Chicago says no comma for last item in a
list; Times says do put one.  However, most US press goes by Chicago so
I'm trying to comply with it.

> Is "multicore" a commonly used word? We might want > to tone down the
> technical feel of the whole release a bit.

Well, we want to mention multi-core or multicore because it's a Buzzword Du
Jour for the tech press.  If you feel that the word needs to be defined,
go for it.

> "has been enhanced" is too much of a passive voice, perhaps we can say
> something like "..manager for 8.1 now scales almost linearly"
>
> I'd put the word "CPU" in there somehow. Non-technical people will
> recognize that more than SMP and "8-way"

Good point.

>
> > Two-Phase Commit (2PC): long in demand for WAN applications and
> > heterogenous data centers using PostgreSQL, this feature allows
> > ACID-compliant transactions across widely separated servers.
>
> <*COUGH* HERE IT IS! (four "e"s) />
>
> s/heterogenous/heterogeneous/

Ah, thanks.  Oddly the ispell dictionary doesn't cover that term ...

> Insert "to be run" before "across"

OK.

> > Bitmapscan:  Some indexes will be automatically converted to bitmaps
> > in memory, giving up to 20x faster index performance on complex
> > queries against very large tables.  Bitmapscan also greatly reduces
> > the need for multi-column indexes.
>
> I think bitmapscan should be two words, not one? And plural?

Well, it's our own word.  And it's in the official PG docs as "BitmapScan"
so I figured stick to that.  Why would it be plural?

> "will be" not quite right in lead sentence, change to "are now
> automatically converted"
>
> s/20x/twenty times/
>
> Is the above 20x figure backed up with data somewhere?

Sure, I've run some queries that showed this much speedup.   It's pretty
rare, though, hence the "up to".   The main reason for order-of-magnitude
speedups is the ability to use an index on queries which weren't
previously indexable, which tends to mean "up to 20x speedup".

> > Roles:  PostgreSQL now supports database roles, which simplify
> > the management of large user bases with complex overlapping
> > database rights.
>
> s/user bases/numbers of users/
>
> > Shared Row Locking: PostgreSQL's "better than row-level
> > locking" has been improved further through the addition of
> > shared row locks for foreign keys.  Shared locks will improve
> > insert and update performance on some OLTP applications.
>
> s/shared locks/shared row locks/

Again, feel free to make edits on the shared version of the doc.

> > Table Partitioning: in version 8.1, the query planner's ability to
> > select the correct table partitions for each query (called Constraint
> > Exclusion) is expanded, making PostgreSQL's table partitioning useful
> > to a broader range of applications.
>
> Do we need to give the technical name in parens? We're not really going
> into details for any of these items, after all.

It's more of a punctuation thing, I didn't want more commas.  However,
you're correct in pointing out that that entry suffers from the Evil Sith
Comma, and needs to be broken into two sentences.

> I'd move this item up higher on the list.

Sure -- what do other people think about the feature order?

> Mention something about the success of the Win32 version, e.g. how this
> is the second major version with Win32, lots of downloads, no problems,
> everyone happy, etc.

Suggested verbiage?

> Mention "hundreds of developers" as in the past?

I think that's in "about PostgreSQL".

> Mention any companies by name?

Just the quoted ones, I think.  Did you have anyone specific in mind?

> Mention our high score in that bug-finder thing?

That's going to be a separate release.

> Mention the new options available (bizgres, enterprisedb, etc.) even if
> only generically?

Hmmm ... suggest wording?

> Emphasize the freedom of the BSD license?

Again, in "about PostgreSQL".

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On Mon, 2005-09-19 at 16:01, Josh Berkus wrote:
> > Is "multicore" a commonly used word? We might want > to tone down the
> > technical feel of the whole release a bit.
>
> Well, we want to mention multi-core or multicore because it's a Buzzword Du
> Jour for the tech press.  If you feel that the word needs to be defined,
> go for it.
>

The buzzword compliant term is "dual-core".


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

Robert,

> The buzzword compliant term is "dual-core".

Hmmm ... doing the google news test:
dual-core: 1134
multi-core: 343
multicore: 196

So they all seem OK as buzzwords.  While "dual-core" is more popular, I'd
prefer to use mult-core because it also covers the chips with 4 and 8
cores which IBM and Sun are planning on.

--Josh

--
__Aglio Database Solutions_______________
Josh Berkus               Consultant
josh@agliodbs.com     www.agliodbs.com
Ph: 415-752-2500    Fax: 415-752-2387
2166 Hayes Suite 200    San Francisco, CA

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


> I thought I'd implemented *all* of your suggestions.  Please copy-edit
> again.  Are you registered for the Press project on pgfoundry?  You could
> make these edits through CVS instead of e-mailing me.

No, I'm not yet, but feel free to set me up (username: turnstep). Of course,
I'm also a big fan of email as we can discuss ideas without actually
committing them. Hmm - I could see a good use of subversions property
tagging for something like that...

>>> 8-way, 16-way and multicore servers.

>> Need a comma after "16-way"

> Actually, that's a style thing.   Chicago says no comma for last item in a
> list; Times says do put one.  However, most US press goes by Chicago so
> I'm trying to comply with it.

I always learned it was a grammar thing, and that the serial comma should
always be included to prevent ambiguity. Even Strunk and White says so.
The only place that omits them anymore is US newspapers, and even there it
is finally dying out. Since this is a global press release, I say we add that
final serial comma in, and weather the storm of angry newspaper editors. ;)

http://www.swcp.com/info/essays/serial-comma.htm
http://www.getitwriteonline.com/archive/021201.htm

> Well, we want to mention multi-core or multicore because it's a Buzzword Du
> Jour for the tech press.  If you feel that the word needs to be defined,
> go for it.

No, that's fine, buzzwords are good. Maybe we can say:

"8-way, 16-way, dual-core, and multi-core servers."

>>> Bitmapscan:  Some indexes will be automatically converted to bitmaps
>>> in memory, giving up to 20x faster index performance on complex
>>> queries against very large tables.  Bitmapscan also greatly reduces
>>> the need for multi-column indexes.
>>
>> I think bitmapscan should be two words, not one? And plural?

> Well, it's our own word.  And it's in the official PG docs as "BitmapScan"
> so I figured stick to that.  Why would it be plural?

I was thinking of plural "bitmap scans" at the start, but it reads well
either way. But it definintely is two words - we even use "bitmaps" alone
in the paragraph, which emphasizes that this is a specific type of scan.
Note that we say "Bitmap Heap Scan" and "Bitmap Index Scan" in our
EXPLAIN output...

> Sure, I've run some queries that showed this much speedup.   It's pretty
> rare, though, hence the "up to".   The main reason for order-of-magnitude
> speedups is the ability to use an index on queries which weren't
> previously indexable, which tends to mean "up to 20x speedup".

Just wanted to COA by asking this before someone else outside the community does.

>> Mention something about the success of the Win32 version, e.g. how this
>> is the second major version with Win32, lots of downloads, no problems,
>> everyone happy, etc.

> Suggested verbiage?

This is the second major version with full native Win32 support. The previous
version saw over 1 billion* downloads for the Windows platform.

* Someone check that figure

>> Mention the new options available (bizgres, enterprisedb, etc.) even if
>> only generically?

> Hmmm ... suggest wording?

Dunno. Could be tricky to tie it into 8.1 specifically.


Thanks for the feedback. This release is coming along a lot smoother than the
last one. Do we also have a draft of the other release yet?

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200509192243
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iD8DBQFDL3fcvJuQZxSWSsgRAqgEAJwKAHOHeW14czJfZe8p67nzs57dxgCcD5Zd
JIZNZq+UibQvYmJMo6hDC/E=
=7TGS
-----END PGP SIGNATURE-----

Greg,

> No, I'm not yet, but feel free to set me up (username: turnstep). Of
> course, I'm also a big fan of email as we can discuss ideas without
> actually committing them. Hmm - I could see a good use of subversions
> property tagging for something like that...

You're added.  SVN will have to wait, though.

> I always learned it was a grammar thing, and that the serial comma should
> always be included to prevent ambiguity. Even Strunk and White says so.
> The only place that omits them anymore is US newspapers, and even there it
> is finally dying out. Since this is a global press release, I say we add
> that final serial comma in, and weather the storm of angry newspaper
> editors. ;)

Well, it's not a grammar thing; it's a style thing.  However, I don't care
that much personally, so I'm fine with putting them in if other people care.

> "8-way, 16-way, dual-core, and multi-core servers."

Sounds good to me.  One of my primary reasons for mentioning it at all is as a
not-very-subtle way of saying "Hey!  PostgreSQL runs on high-end hardware!"

> I was thinking of plural "bitmap scans" at the start, but it reads well
> either way. But it definintely is two words - we even use "bitmaps" alone
> in the paragraph, which emphasizes that this is a specific type of scan.
> Note that we say "Bitmap Heap Scan" and "Bitmap Index Scan" in our
> EXPLAIN output...

Hmm ... so "Bitmap Scan" then as the name of the feature?

> Just wanted to COA by asking this before someone else outside the community
> does.

Yes.  I figure the "up to" protects us some.

> This is the second major version with full native Win32 support. The
> previous version saw over 1 billion* downloads for the Windows platform.
>
> * Someone check that figure

Try 700,000.

>
> >> Mention the new options available (bizgres, enterprisedb, etc.) even if
> >> only generically?
> >
> > Hmmm ... suggest wording?
>
> Dunno. Could be tricky to tie it into 8.1 specifically.

Yes.  Let me know if inspiration strikes.

> Thanks for the feedback. This release is coming along a lot smoother than
> the last one.

Experience.

> Do we also have a draft of the other release yet?

No, I'm waiting to see the official Coverity report.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Mon, Sep 19, 2005 at 01:01:19PM -0700, Josh Berkus wrote:
> > Emphasize the freedom of the BSD license?
>
> Again, in "about PostgreSQL".

I'm not sure what the best way to do this is, but I think more emphasis
about what being BSD licensed means for corporations would be good.
We're seeing companies that are pleasantly surprised to find out how
much more flexible dealing with PostgreSQL is from a licensing
standpoint than certain other 'free as in herpes' databases.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

Jim C. Nasby wrote:

>On Mon, Sep 19, 2005 at 01:01:19PM -0700, Josh Berkus wrote:
>
>
>>>Emphasize the freedom of the BSD license?
>>>
>>>
>>Again, in "about PostgreSQL".
>>
>>
>
>I'm not sure what the best way to do this is, but I think more emphasis
>about what being BSD licensed means for corporations would be good.
>We're seeing companies that are pleasantly surprised to find out how
>much more flexible dealing with PostgreSQL is from a licensing
>standpoint than certain other 'free as in herpes' databases.
>
>
I can concur with this. I have had several large customers
come to CMD + PostgreSQL, just because the other guys
are GPL.

It didn't matter that we were a better database. They just
didn't like the license.

Sincerely,

Joshua D. Drake





--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Tue, 2005-09-20 at 02:46 +0000, Greg Sabino Mullane wrote:

> "8-way, 16-way, dual-core, and multi-core servers."

Perhaps I missed something? Is there a publicly accessible benchmark of
a 16-way CPU system? I wasn't aware sufficient info was in the public
domain to allow us to reasonably discuss that?

Links anybody, for the press pack?

Best Regards, Simon Riggs

Simon,

> Perhaps I missed something? Is there a publicly accessible benchmark of
> a 16-way CPU system? I wasn't aware sufficient info was in the public
> domain to allow us to reasonably discuss that?

Hmmm ... that would be good to have, yes.   I'll ask Mark.

--Josh

--
__Aglio Database Solutions_______________
Josh Berkus               Consultant
josh@agliodbs.com     www.agliodbs.com
Ph: 415-752-2500    Fax: 415-752-2387
2166 Hayes Suite 200    San Francisco, CA

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


> You're added.  SVN will have to wait, though.

Thanks.

> Sounds good to me.  One of my primary reasons for mentioning it at all is as a
> not-very-subtle way of saying "Hey!  PostgreSQL runs on high-end hardware!"

Yep.

> Hmm ... so "Bitmap Scan" then as the name of the feature?

Sounds good to me. I'll try out my new cvs right and Make It So.

BTW, do the cvs commits go to a mailing list yet?

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200509221416
https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkMy9eoACgkQvJuQZxSWSshvOwCg25C3mHlbzMz8Z1ZouQxhFfzm
OGgAoL5huB8e/hUPkT1AAqxvMu6kYHGN
=0eiv
-----END PGP SIGNATURE-----

Josh, all:

> >I'm not sure what the best way to do this is, but I think more emphasis
> >about what being BSD licensed means for corporations would be good.
> >We're seeing companies that are pleasantly surprised to find out how
> >much more flexible dealing with PostgreSQL is from a licensing
> >standpoint than certain other 'free as in herpes' databases.
>
> I can concur with this. I have had several large customers
> come to CMD + PostgreSQL, just because the other guys
> are GPL.

Good points all.

However, I'd rather not make a big point of the license in this release.
We did that with the last release (which paid dividends) but I think
everyone knows about it now.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On Thu, Sep 29, 2005 at 05:38:30PM -0700, Josh Berkus wrote:
> Josh, all:
>
> > >I'm not sure what the best way to do this is, but I think more emphasis
> > >about what being BSD licensed means for corporations would be good.
> > >We're seeing companies that are pleasantly surprised to find out how
> > >much more flexible dealing with PostgreSQL is from a licensing
> > >standpoint than certain other 'free as in herpes' databases.
> >
> > I can concur with this. I have had several large customers
> > come to CMD + PostgreSQL, just because the other guys
> > are GPL.
>
> Good points all.
>
> However, I'd rather not make a big point of the license in this release.
> We did that with the last release (which paid dividends) but I think
> everyone knows about it now.

Going to have to disagree there. Actually, every commercial entity I've
talked to since starting at Pervasive either thought PostgreSQL was
GPL'd or had next to no understanding about what it's licensing was. In
every case, they were the ones asking the question, and in every case
they were very pleasantly surprised to find out about the licensing.

We can debate about whether the license should be mentioned in the
release or not, but I definitely think that there's still a whole lot of
people who should be educated about our license and what it means to
them.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

>We can debate about whether the license should be mentioned in the
>release or not, but I definitely think that there's still a whole lot of
>people who should be educated about our license and what it means to
>them.
>
>
I agree with Jim here. We don't have to make a big deal in the release
but it should be
mentioned. A simple one liner:

PostgreSQL is licensed under the truly free BSD license.

Yes it is a little flame bait but it works.

Joshua D. Drake





--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Josh, Jim,

> I agree with Jim here. We don't have to make a big deal in the release
> but it should be
> mentioned. A simple one liner:

Can you take a look at how the release looks now?   It has the line we put in
last year about the BSD license in "About PostgreSQL".   Do we need to do
more than that?

>
> PostgreSQL is licensed under the truly free BSD license.

I'm definitely going to oppose anything that looks like picking a picking a
fight with the FSF.  It doesn't pay.

--
Josh Berkus
Aglio Database Solutions
San Francisco

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


> However, I'd rather not make a big point of the license in this release.
> We did that with the last release (which paid dividends) but I think
> everyone knows about it now.

Huh? That's a weird argument. Even if true, it's no reason not to
include it in a press release.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200509300941
https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkM9QKMACgkQvJuQZxSWSshqmACgoJeBd4zluY+BsT8cZz3+jP0V
SD0AoISByzYgE29T4z6OB5qGmINt90oL
=x5Z3
-----END PGP SIGNATURE-----

On 9/30/05, Greg Sabino Mullane <greg@turnstep.com> wrote:
> > However, I'd rather not make a big point of the license in this release.
> > We did that with the last release (which paid dividends) but I think
> > everyone knows about it now.
>
> Huh? That's a weird argument. Even if true, it's no reason not to
> include it in a press release.

As a largely pointless data sample, when I wrote a blog posting
bemoaning the "least common denominator" of MySQL, I had several
people write me that the reason it was popular was that "it's free,
and no other is."

Beat the drum. Don't attack (that's my job :-), but make it clear that
not only is PostgreSQL "free" (as in beer) it's "business friendly."

Chris
--
| Christopher Petrilli
| petrilli@gmail.com

On 9/30/05, Christopher Petrilli <petrilli@gmail.com> wrote:
>
> Beat the drum. Don't attack (that's my job :-), but make it clear that
> not only is PostgreSQL "free" (as in beer) it's "business friendly."

I agree with this sentiment completely. There is a great amount of
confusion and debate about the GPL and it's implications on business.
PostgreSQL being released under the BSD should be a huge
differentiating factor, and should be a prominent attribute in press
releases.

This is a good thing, and there is no need to take shots at the GPL,
you should be able to stand up and say "There's no questions with the
BSD!" You can use the GPL uncertainty to your advantage, and educate
the business community at the same time.

My $0.02.

-- Mitch

>>PostgreSQL is licensed under the truly free BSD license.
>>
>>
>
>I'm definitely going to oppose anything that looks like picking a picking a
>fight with the FSF.  It doesn't pay.
>
>
O.k. relax people :) It was supposed to be a little bit of a joke. I
would never expect that
we would say that. However something along the lines of Mitch's suggestions:

"There's no questions with the BSD!"

Or maybe:

"There's no risk with the BSD! license"

"The most flexible OSS database because of its BSD License!"

Sincerely,

Joshua D. Drake



--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

The other thing that i have said to people on this, as to say
something about it but also as a half dodge

"what is yours stays yours"

Brian

On Sep 30, 2005, at 11:21 AM, Joshua D. Drake wrote:

>
>
>>> PostgreSQL is licensed under the truly free BSD license.
>>>
>>>
>>
>> I'm definitely going to oppose anything that looks like picking a
>> picking a fight with the FSF.  It doesn't pay.
>>
>>
> O.k. relax people :) It was supposed to be a little bit of a joke.
> I would never expect that
> we would say that. However something along the lines of Mitch's
> suggestions:
>
> "There's no questions with the BSD!"
>
> Or maybe:
>
> "There's no risk with the BSD! license"
>
> "The most flexible OSS database because of its BSD License!"
>
> Sincerely,
>
> Joshua D. Drake
>
>
>
> --
> Your PostgreSQL solutions company - Command Prompt, Inc.
> 1.800.492.2240
> PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
> Managed Services, Shared and Dedicated Hosting
> Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

How about instead looking at this issue by trying to define a short
statement about postgres which should be included in every release,
and mentions the license. This is typically how this problem would be
approached in any other PR situation. I think most folks agree that
the license aspect of PG is very appealing and should be called out
as often as possible. By incorporating it into some kind of standard
language that's included in all PG-related releases and
communications, releases can focus on new features and 'news' while
still including the crucial BSD license advantage.

I'm not sure if this is already in place, but I figure its a good way
to approach the issue.
___________________________________
Javier Soltero
Hyperic                  |  www.hyperic.net
o- 415 738 2566  |  c- 415 305 8733
javier.soltero@hyperic.net
___________________________________

On Sep 30, 2005, at 6:43 AM, Greg Sabino Mullane wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>> However, I'd rather not make a big point of the license in this
>> release.
>> We did that with the last release (which paid dividends) but I think
>> everyone knows about it now.
>>
>
> Huh? That's a weird argument. Even if true, it's no reason not to
> include it in a press release.
>
> - --
> Greg Sabino Mullane greg@turnstep.com
> PGP Key: 0x14964AC8 200509300941
> https://www.biglumber.com/x/web?
> pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
>
> -----BEGIN PGP SIGNATURE-----
>
> iEYEARECAAYFAkM9QKMACgkQvJuQZxSWSshqmACgoJeBd4zluY+BsT8cZz3+jP0V
> SD0AoISByzYgE29T4z6OB5qGmINt90oL
> =x5Z3
> -----END PGP SIGNATURE-----
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

Javier, Josh, Mitch, etc.:

> How about instead looking at this issue by trying to define a short
> statement about postgres which should be included in every release,

You know, all of your feedback would be *much* more useful if you
actually read the release I have up, currently.   I'll repeat, because
nobody on *this* thread has once referred to this fact:

The "ABOUT POSTGRESQL" statement contains a mention of the BSD license
and its business-friendliness.

Now, all of you, please read the release and make comments on what's
actually there, thanks.

http://pgfoundry.org/docman/view.php/1000047/85/release.txt

The question is not whether we need to mention our license.   That's
already there.  It's whether it needs more emphasis than it's already
getting, like the phrase "released under the flexible BSD license" in
the first paragraph.

--Josh

Ouch :)

I did read the release, man. Sorry if that didnt come through in my
comments. I just wanted to advocate we stick to mentioning the
license in the "ABOUT" section rather than calling it out in every
announcement.

___________________________________
Javier Soltero
Hyperic                  |  www.hyperic.net
o- 415 738 2566  |  c- 415 305 8733
javier.soltero@hyperic.net
___________________________________

On Sep 30, 2005, at 10:20 AM, Josh Berkus wrote:

> Javier, Josh, Mitch, etc.:
>
>
>> How about instead looking at this issue by trying to define a
>> short  statement about postgres which should be included in every
>> release,
>>
>
> You know, all of your feedback would be *much* more useful if you
> actually read the release I have up, currently.   I'll repeat,
> because nobody on *this* thread has once referred to this fact:
>
> The "ABOUT POSTGRESQL" statement contains a mention of the BSD
> license and its business-friendliness.
>
> Now, all of you, please read the release and make comments on
> what's actually there, thanks.
>
> http://pgfoundry.org/docman/view.php/1000047/85/release.txt
>
> The question is not whether we need to mention our license.
> That's already there.  It's whether it needs more emphasis than
> it's already getting, like the phrase "released under the flexible
> BSD license" in the first paragraph.
>
> --Josh
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

----
Bitmap Scan:  some indexes will be automatically converted to
bitmaps in memory, giving up to 20x faster index performance on
complex queries against against very large tables, such as those
found in data marts. Bitmap Scan also greatly reduces the need
for multi-column indexes.

Bitmap Scan: indexes will be automatically converted when appropriate...

when needed

----

----
Shared Row Locking: PostgreSQL's "better than row-level
locking" has been improved further through the addition of
shared row locks for foreign keys.  Shared locks will improve
insert and update performance on some OLTP applications
                     ^^^^

The word "some" sounds like it is a minority of OLTP applications.
In general any moderately used OLTP app will benifit from this yes?

many, most, or just say performance on OLTP applications.

---



Josh Berkus wrote:
> Javier, Josh, Mitch, etc.:
>
>> How about instead looking at this issue by trying to define a short
>> statement about postgres which should be included in every release,
>
>
> You know, all of your feedback would be *much* more useful if you
> actually read the release I have up, currently.   I'll repeat, because
> nobody on *this* thread has once referred to this fact:
>
> The "ABOUT POSTGRESQL" statement contains a mention of the BSD license
> and its business-friendliness.
>
> Now, all of you, please read the release and make comments on what's
> actually there, thanks.
>
> http://pgfoundry.org/docman/view.php/1000047/85/release.txt
>
> The question is not whether we need to mention our license.   That's
> already there.  It's whether it needs more emphasis than it's already
> getting, like the phrase "released under the flexible BSD license" in
> the first paragraph.
>
> --Josh
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

I think converted is the wrong word.  Maybe "stored".

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

Joshua D. Drake wrote:
> ----
> Bitmap Scan:  some indexes will be automatically converted to
> bitmaps in memory, giving up to 20x faster index performance on
> complex queries against against very large tables, such as those
> found in data marts. Bitmap Scan also greatly reduces the need
> for multi-column indexes.
>
> Bitmap Scan: indexes will be automatically converted when appropriate...
>
> when needed
>
> ----
>
> ----
> Shared Row Locking: PostgreSQL's "better than row-level
> locking" has been improved further through the addition of
> shared row locks for foreign keys.  Shared locks will improve
> insert and update performance on some OLTP applications
>                      ^^^^
>
> The word "some" sounds like it is a minority of OLTP applications.
> In general any moderately used OLTP app will benifit from this yes?
>
> many, most, or just say performance on OLTP applications.
>
> ---
>
>
>
> Josh Berkus wrote:
> > Javier, Josh, Mitch, etc.:
> >
> >> How about instead looking at this issue by trying to define a short
> >> statement about postgres which should be included in every release,
> >
> >
> > You know, all of your feedback would be *much* more useful if you
> > actually read the release I have up, currently.   I'll repeat, because
> > nobody on *this* thread has once referred to this fact:
> >
> > The "ABOUT POSTGRESQL" statement contains a mention of the BSD license
> > and its business-friendliness.
> >
> > Now, all of you, please read the release and make comments on what's
> > actually there, thanks.
> >
> > http://pgfoundry.org/docman/view.php/1000047/85/release.txt
> >
> > The question is not whether we need to mention our license.   That's
> > already there.  It's whether it needs more emphasis than it's already
> > getting, like the phrase "released under the flexible BSD license" in
> > the first paragraph.
> >
> > --Josh
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
>
>
> --
> Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
> PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
> Managed Services, Shared and Dedicated Hosting
> Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

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

Bruce Momjian wrote:
> I think converted is the wrong word.  Maybe "stored".

Good point...

indexes will be automatically stored as bitmaps in RAM...

>
> ---------------------------------------------------------------------------
>
> Joshua D. Drake wrote:
>
>>----
>>Bitmap Scan:  some indexes will be automatically converted to
>>bitmaps in memory, giving up to 20x faster index performance on
>>complex queries against against very large tables, such as those
>>found in data marts. Bitmap Scan also greatly reduces the need
>>for multi-column indexes.
>>
>>Bitmap Scan: indexes will be automatically converted when appropriate...
>>
>>when needed
>>
>>----
>>
>>----
>>Shared Row Locking: PostgreSQL's "better than row-level
>>locking" has been improved further through the addition of
>>shared row locks for foreign keys.  Shared locks will improve
>>insert and update performance on some OLTP applications
>>                     ^^^^
>>
>>The word "some" sounds like it is a minority of OLTP applications.
>>In general any moderately used OLTP app will benifit from this yes?
>>
>>many, most, or just say performance on OLTP applications.
>>
>>---
>>
>>
>>
>>Josh Berkus wrote:
>>
>>>Javier, Josh, Mitch, etc.:
>>>
>>>
>>>>How about instead looking at this issue by trying to define a short
>>>>statement about postgres which should be included in every release,
>>>
>>>
>>>You know, all of your feedback would be *much* more useful if you
>>>actually read the release I have up, currently.   I'll repeat, because
>>>nobody on *this* thread has once referred to this fact:
>>>
>>>The "ABOUT POSTGRESQL" statement contains a mention of the BSD license
>>>and its business-friendliness.
>>>
>>>Now, all of you, please read the release and make comments on what's
>>>actually there, thanks.
>>>
>>>http://pgfoundry.org/docman/view.php/1000047/85/release.txt
>>>
>>>The question is not whether we need to mention our license.   That's
>>>already there.  It's whether it needs more emphasis than it's already
>>>getting, like the phrase "released under the flexible BSD license" in
>>>the first paragraph.
>>>
>>>--Josh
>>>
>>>
>>>---------------------------(end of broadcast)---------------------------
>>>TIP 2: Don't 'kill -9' the postmaster
>>
>>
>>--
>>Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
>>PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
>>Managed Services, Shared and Dedicated Hosting
>>Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 3: Have you checked our extensive FAQ?
>>
>>               http://www.postgresql.org/docs/faq
>>
>
>


--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Javier,

> I did read the release, man. Sorry if that didnt come through in my
> comments. I just wanted to advocate we stick to mentioning the
> license in the "ABOUT" section rather than calling it out in every
> announcement.

Sorry.   I just got 10 comments on that thread, and not one of them
referred to the ABOUT POSTGRESQL section.   Yours was phrased as
suggesting we draft one, which seemed to say you hadn't read it.  Sorry!

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

Bruce,

> I think converted is the wrong word.  Maybe "stored".

But they're *not* stored as bitmaps.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

On Fri, 2005-09-30 at 13:31, Joshua D. Drake wrote:
> Shared Row Locking: PostgreSQL's "better than row-level
> locking" has been improved further through the addition of
> shared row locks for foreign keys.  Shared locks will improve
> insert and update performance on some OLTP applications
>                      ^^^^
>
> The word "some" sounds like it is a minority of OLTP applications.
> In general any moderately used OLTP app will benifit from this yes?
>
> many, most, or just say performance on OLTP applications.
>

well, it will really only help on those systems that were stressing out
our current design (and thats really hardware dependent too) so maybe
"busy", "heavy","high load" or just  "on OLTP applications".


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

On Fri, Sep 30, 2005 at 04:13:45PM -0400, Robert Treat wrote:
> On Fri, 2005-09-30 at 13:31, Joshua D. Drake wrote:
> > Shared Row Locking: PostgreSQL's "better than row-level
> > locking" has been improved further through the addition of
> > shared row locks for foreign keys.  Shared locks will improve
> > insert and update performance on some OLTP applications
> >                      ^^^^
> >
> > The word "some" sounds like it is a minority of OLTP applications.
> > In general any moderately used OLTP app will benifit from this yes?
> >
> > many, most, or just say performance on OLTP applications.
>
> well, it will really only help on those systems that were stressing out
> our current design (and thats really hardware dependent too) so maybe
> "busy", "heavy","high load" or just  "on OLTP applications".

It will help applications that use foreign keys extensively.  Do "most
OLTP apps" do that?  I guess any reasonably implemented app should.

--
Alvaro Herrera                  http://www.amazon.com/gp/registry/DXLWNGRJD34
Thou shalt check the array bounds of all strings (indeed, all arrays), for
surely where thou typest "foo" someone someday shall type
"supercalifragilisticexpialidocious" (5th Commandment for C programmers)

Joshua D. Drake wrote:
>
>> We can debate about whether the license should be mentioned in the
>> release or not, but I definitely think that there's still a whole lot of
>> people who should be educated about our license and what it means to
>> them.
>>
>>
> I agree with Jim here. We don't have to make a big deal in the release
> but it should be
> mentioned. A simple one liner:
>
> PostgreSQL is licensed under the truly free BSD license.
>
> Yes it is a little flame bait but it works.

I'm following an "embedded" project where we are going to use Postgresql,
before my join the idea was to use MySQL because the general idea was:
it's free. I spent some days before to make them understand that MySQL for
their project was not free and in the other side Posgresql is, in last
periods arguments as: MySQL doesn't have transaction doesn't work anymore.

Unfortunatelly is common believing that GNU, BSD, GPL licenses are totally
free. I think it's better specify that with Postgres you can do whatever
you want without any obligation of any sort now and for ever.


Regards
Gaetano Mendola

On 9/30/05, Gaetano Mendola <mendola@bigfoot.com> wrote:
>
> Unfortunatelly is common believing that GNU, BSD, GPL licenses are totally
> free. I think it's better specify that with Postgres you can do whatever
> you want without any obligation of any sort now and for ever.

I agree, and have reviewed both versions of the proposed release and
think that there should be a short paragraph, instead of the one line
mention of the BSD license. I really think that right now NOT having a
GPL license and being truly free, is a huge advantage to PostgreSQL.

Trust me on this one, from personal experience!

-- Mitch, rubbing a very sore backside from licensing issues *cough*

On Friday 30 September 2005 21:14, Alvaro Herrera wrote:
> On Fri, Sep 30, 2005 at 04:13:45PM -0400, Robert Treat wrote:
> > On Fri, 2005-09-30 at 13:31, Joshua D. Drake wrote:
> > > Shared Row Locking: PostgreSQL's "better than row-level
> > > locking" has been improved further through the addition of
> > > shared row locks for foreign keys.  Shared locks will improve
> > > insert and update performance on some OLTP applications
> > >             ^^^^
> > >
> > > The word "some" sounds like it is a minority of OLTP applications.
> > > In general any moderately used OLTP app will benifit from this yes?
> > >
> > > many, most, or just say performance on OLTP applications.
> >
> > well, it will really only help on those systems that were stressing out
> > our current design (and thats really hardware dependent too) so maybe
> > "busy", "heavy","high load" or just  "on OLTP applications".
>
> It will help applications that use foreign keys extensively.  Do "most
> OLTP apps" do that?  I guess any reasonably implemented app should.

ISTM it depends on how you define help.  If your running an OLTP system on
current releases, and you dont have performance/deadlock issues, then this
isn't going to do much for you.

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

Merlin,

> Database Administrator.  I will get approval plus more advocacy related
> information ASAP (today).

I never saw an e-mail from you approving your quote.   Please take a look
at the slightly altered text:

"PostgreSQL 8.1 offers a huge performance increase pretty much
across the board, [on our] dual processor Opteron production
servers," said Merlin Moncure, Database Administrator for
Reliable Computer Solutions.
"More specifically, I'm seeing around 20% reduction in run times
for simple queries and an additional 20%
reduction in cpu load, for a staggering 20-40% improvement in
server load characteristics."


--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco