Re: Time to start the PR machine

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-advocacy(at)postgresql(dot)org
Cc: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Subject: Re: Time to start the PR machine
Date: 2005-09-19 20:01:19
Message-ID: 200509191301.19227.josh@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy

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

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Marc G. Fournier 2005-09-19 20:20:30 Re: Release dateline :-(
Previous Message Greg Sabino Mullane 2005-09-19 19:44:33 Re: Time to start the PR machine