Re: Time to start the PR machine

From: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
To: pgsql-advocacy(at)postgresql(dot)org
Subject: Re: Time to start the PR machine
Date: 2005-09-20 02:46:16
Message-ID: affe19eeea512d9f3cf1fc3d6a800e87@biglumber.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy


-----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(at)turnstep(dot)com
PGP Key: 0x14964AC8 200509192243
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

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

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

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Richard P. Welty 2005-09-20 02:54:27 Re: Release dateline :-(
Previous Message Bruce Momjian 2005-09-20 02:20:05 Re: Release dateline :-(