Re: Sixth Draft - Mailing list pgsql-advocacy

> Josh Berkus wrote
> 200 developers:   We need to get a firm count from the patches
> list before
> going live with this.   I'll ask Bruce.
>

IMHO we should count anybody that submitted a patch, whether ot not it was
applied. That is a true measure of the size of the community, as well as
being a clear statement that we have a quality gate that doesn't always let
code in.

> In addition to reaching a new milestone in scalability, PostgreSQL 8.0
> demonstrates the unparalleled development ability of open source.
>  Red Hat,
> Fujitsu, Afilias, SRA of Japan, 2nd Quadrant, Command Prompt, and
> more than a
> dozen other companies as well as over 200 individual developers
> contributed
> to add more major features to 8.0 than have been seen in any previous
> version.   These features include:

Thanks. Good to receive the compliment of being allowed to complement such
fine contributors. :)

> Point In Time Recovery: PITR provides "continuous backup",
> allowing minimal
> loss of data even in the event of total hardware failure.

PITR is the way we talk about it on PostgreSQL lists, but that isn't
necessarily the best thing to call it externally. Using the abbreviation
probably doesn't help the general reader of the press release - its not
mentioned again in the press release, so no gain there either. I'd suggest
just start talking "...provides" and drop the word PITR. Microsoft use the
phrase "Point in Time Recovery", though Oracle and IBM do not. (IBM did use
the term for their IMS database product, which is still in use somewhere,
I'm sure, but not as prevalent these last few decades).

Terminology wise, "continuous backup" isn't a phrase I recognise either.

Microsoft refers to the "SQL Server Transaction Log" and the "Full recovery
model"
Oracle refers to "log files" and operates in "archivelog mode"
DB2 refers to "log files" and operates in "archive logging mode"

My suggested rewording of this particular paragraph would be the following:
--
Point in Time Recovery: provides a full recovery model that allows data
recovery from bare-metal to the point of failure or to a specific point in
time, based around automatically archived transaction logs.
--

> Tablespaces:  crucial to the administrators of multi-gigabyte
> data warehousing
> systems, tablespaces allow the placement of large tables and
> indexes on their
> own individual disks or arrays.

I'm not sure this applies just to data warehousing systems, though it is of
course very useful in that context.

Certainly, it is a great boon in any large and heavily used database... most
DBAs would know and appreciate this feature.

"simplies management of..."

Best Regards, Simon Riggs