Re: Beta1 announcement: alpha1 draft
От | Robert Haas |
---|---|
Тема | Re: Beta1 announcement: alpha1 draft |
Дата | |
Msg-id | CA+TgmoatS1pXn7j=25vS_AfjuC=wSX2GuOGwF=8Wkjbj2HvZbA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Beta1 announcement: alpha1 draft (Josh berkus <josh@agliodbs.com>) |
Список | pgsql-advocacy |
On Tue, Apr 26, 2016 at 11:46 PM, Josh berkus <josh@agliodbs.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
В списке pgsql-advocacy по дате отправления: