Re: Beta1 announcement: alpha1 draft

On Tue, Apr 26, 2016 at 11:46 PM, Josh berkus <josh(at)agliodbs(dot)com> wrote:
> On 04/26/2016 06:49 PM, Robert Haas wrote:
>> IMHO, your "rephrasing" has made this much worse. You changed the
>> description of multiple synchronous standbys so that it now mentions
>> only multiple synchronous standbys and omits all mention of
>> synchronous_commit=remote_apply;
>
> If we're going to mention remote_apply, then we need to explain what it
> means. Got a 1-sentence description?

I think that what we want to convey is that you can now build
read-scaling clusters using PostgreSQL that are actually reliable.
synchronous_commit=remote_apply provides the reliability, because now
you can guarantee that the data is visible on the remote nodes, not
just in the queue to be applied. And the multiple synchronous
standbys feature allows you to extend that guarantee to as many nodes
as you've got. Now, how to phrase that in one sentence, I'm not quite
sure. Maybe:

* new synchronous replication features, making it possible to build
reliable read-scaling clusters

But that'd need some meat on the bones elsewhere.

>> You changed the description of pushdown for FDW so that it no longer
>> talks about direct updates, just sort and join pushdown.
>
> Probably direct updates should be its own line then. Suggested phrasing?

I think it can maybe be all one line, like this:

* allow postgres_fdw to push sorts, joins, UPDATEs, and DELETEs to
remote servers

The upshot is that, apart from particular features, people can expect
postgres_fdw to deliver significantly better performance in a bunch of
situations than it did before. Sadly, there wasn't time to get
aggregate pushdown done for this release, or we would really have had
something to boast about. But it's still a good story.

>> And you
>> changed the description of the freeze map changes so that it's wildly
>> inaccurate.
>
> Again, "so WTH should I care if there's a freeze bit on the visibility
> map? This means what to me?" We have to explain why these features
> matter to users instead of just giving technical detail. Save the
> technical detail for the release notes.

Well, what you said is that freezing is more efficient. That
presupposes that people know what freezing is. If they do, and they
read that, they're going to think that the freezing itself happens
faster, which isn't true. What we want them to understand is that we
can skip repeatedly freezing the same stuff. So, you could say, for
example:

* avoid repeatedly freezing the same old data, decreasing the impact
of autovacuum activity

That uses no technical term that your version doesn't.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company