Thread: Beta1 announcement: alpha1 draft
Hello, Here is a alpha draft of the Beta1 announcement. I am aware it is not complete as I don't have release notes yet. PostgreSQL 9.6 Beta1 Released! The PostgreSQL Global Development Group announces today that the first beta release of PostgreSQL 9.6 is available for download. This is a feature freeze release and should contain all features and APIs which will be in the final release. Users should begin testing their applications against 9.6 Beta 1 in preparation for the final release. Major changes since 9.5 The 9.6 features several significant changes and exciting enhancements including: * Parallelism for certain queries (see max_parallel_degree) * Increased logical decoding features * Full Text Search improvements * Join Pushdown for postgres-fdw * Enable pg_dump ACL support In particular, the the parallelism feature should bring a noticeable increase in performance to supported queries. Beta Schedule This is first beta release of version 9.6, indicating that very few user-visible feature changes are expected before final release. The PostgreSQL Project will release additional betas as required for testing, followed by one or more release candidates, until the final release in late 2016. For further information please see: http://www.postgresql.org/docs/devel/static/release-9-5-2.html (Update to 9.6GBeta1) Notable upcoming community releases PgAdmin4 is in preview mode (insert link) PgLogical is available for testing (insert link) -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On Tue, Apr 26, 2016 at 1:58 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > The 9.6 features several significant changes and exciting enhancements > including: I suggest looking at this list: https://en.wikipedia.org/wiki/PostgreSQL#Upcoming_features > * Parallelism for certain queries (see max_parallel_degree) Good. The Wikipedia page phrases it more specifically as "Parallel sequential scans, parallel joins and parallel aggregates" which is maybe a bit more specific and perhaps better for that reason? > * Increased logical decoding features I don't see the logical decoding features as being of much interest for general users, although maybe I'm wrong about that. > * Full Text Search improvements I think the main thing here is phrase search; maybe we should say that instead. > * Join Pushdown for postgres-fdw I think this could be a bit more general. The Wikipedia page phrase it as "Sort pushdown, join pushdown and DML (UPDATE/DELETE) pushdown for postgres_fdw." Sort pushdown is of less interest than join pushdown, but DML pushdown seems like a big deal. > * Enable pg_dump ACL support I'm not entirely sure anyone will know what this is or why they should care. It might be worth mentioning if we can clarify that. Also note we now have: Extension cascade support to install dependencies Cube extension kNN support Command progress reporting for VACUUM Detailed wait information in pg_stat_activity Frozen page data in visibility map for skipping vacuum on already-frozen data New remote_apply replication mode which waits for confirmation that a standby has applied changes Index-only scans for partial indexes Support for multiple synchronous standbys User-defined expiration of snapshots to control table bloat I think there are a decent number of people for whom the frozen page data in the visibility map will be a really big deal, even bigger than parallel query. And I think the combination of synchronous_commit=remote_apply and multiple synchronous standbys is also going to be really, really useful for anyone who wants to build a robust read-scaling cluster around PostgreSQL. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
* Robert Haas (robertmhaas@gmail.com) wrote: > On Tue, Apr 26, 2016 at 1:58 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > > * Enable pg_dump ACL support > > I'm not entirely sure anyone will know what this is or why they should > care. It might be worth mentioning if we can clarify that. Err, worse, that particular comment is just wrong- pg_dump has supported dumping ACLs for a very long time, we're just now supporting dumping ACLs for objects in pg_catalog (and objects which are members of extensions) which are changed from their default. > Also note we now have: Note sure why it isn't working at the moment (at least for me), but when it does, you could also check out: http://www.hagander.net/talks/ And look at Magnus' "A Look Inside the Elephant's Trunk - 9.6" talk. > I think there are a decent number of people for whom the frozen page > data in the visibility map will be a really big deal, even bigger than > parallel query. Agreed, for certain users, that's huge. > And I think the combination of > synchronous_commit=remote_apply and multiple synchronous standbys is > also going to be really, really useful for anyone who wants to build a > robust read-scaling cluster around PostgreSQL. Agreed. Thanks! Stephen
Attachment
On 04/26/2016 11:08 AM, Robert Haas wrote: > On Tue, Apr 26, 2016 at 1:58 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >> The 9.6 features several significant changes and exciting enhancements >> including: > > I suggest looking at this list: > > https://en.wikipedia.org/wiki/PostgreSQL#Upcoming_features Well that is exceedingly helpful. Thank you :D I will post a new version shortly! Sincerely, jD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
And phase 2...
Note, I am purposely limiting the features we list to a maximum of 5.
This is just a beta announcement, we need people to read it and anything
longer than one page and we lose the majority of the audience.
PostgreSQL 9.6 Beta1 Released!
The PostgreSQL Global Development Group announces today that the first
beta release of PostgreSQL 9.6 is available for download. This is a
feature freeze release and should contain all features and APIs of the
final release. Users are encouraged to begin testing their applications
against this latest release.
Major changes since 9.5
The 9.6 features several significant changes and exciting enhancements
including:
* Parallel sequential scans, joins and aggregates
* Enhanced synchronous replication support with Support for multiple
synchronous standby and remote_apply confirmation.
* Phrase full text search
* Pushdown support for joins, DML (UPDATE/DELETE) and sorts for
postgres_fdw
* Frozen page data in visibility map for skipping vacuum on
already-frozen data
In particular, the the parallelism feature should bring a noticeable
increase in performance to supported queries.
Beta Schedule
This is first beta release of version 9.6, indicating that very few
user-visible feature changes are expected before final release. The
PostgreSQL Project will release additional betas as required for
testing, followed by one or more release candidates, until the final
release in late 2016. For further information please see:
* http://www.postgresql.org/docs/devel/static/release-9-5-2.html
* (Update to 9.6GBeta1)
Notable upcoming community releases
* PgAdminIV is in preview mode (insert link)
* PgLogical is available for testing (insert link)
* Apache MADlib: an open source analytics library for PostgreSQL (insert
link)
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
On Tue, Apr 26, 2016 at 8:27 PM, Stephen Frost <sfrost@snowman.net> wrote:
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Apr 26, 2016 at 1:58 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> > * Enable pg_dump ACL support
>
> I'm not entirely sure anyone will know what this is or why they should
> care. It might be worth mentioning if we can clarify that.
Err, worse, that particular comment is just wrong- pg_dump has supported
dumping ACLs for a very long time, we're just now supporting dumping
ACLs for objects in pg_catalog (and objects which are members of
extensions) which are changed from their default.
> Also note we now have:
Note sure why it isn't working at the moment (at least for me), but when
it does, you could also check out:
http://www.hagander.net/talks/
And look at Magnus' "A Look Inside the Elephant's Trunk - 9.6" talk.
Ugh that was indeed broken. Thanks for pointing it out - fixed now, and the slides are there.
JD, Thank you for kicking this off! I've created a wiki page based on the content from this thread, for better collaboration. https://wiki.postgresql.org/wiki/9.6betareleasedraft Changes I made: 1. adding template content from prior beta releases 2. rephrasing some features to try to make them clearer to casual users (this still needs help) 3. Noting that API/feature changes may still happen, because they may. In fact, we're pretty sure that we're at least changing a few GUC names. -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
On 04/26/2016 05:08 PM, Josh berkus wrote: > JD, > > Thank you for kicking this off! > > I've created a wiki page based on the content from this thread, for > better collaboration. > > https://wiki.postgresql.org/wiki/9.6betareleasedraft > > Changes I made: > > 1. adding template content from prior beta releases > > 2. rephrasing some features to try to make them clearer to casual users > (this still needs help) > > 3. Noting that API/feature changes may still happen, because they may. > In fact, we're pretty sure that we're at least changing a few GUC names. > You removed the kudos to other upcoming stuff that is outside of core. I think that is a mistake. We are an inclusive community. Including tips to users about awesome stuff that uses PostgreSQL is a good thing. A press release that pushes our inclusiveness as a point, is a very good thing. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On Tue, Apr 26, 2016 at 9:19 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > You removed the kudos to other upcoming stuff that is outside of core. I > think that is a mistake. We are an inclusive community. Including tips to > users about awesome stuff that uses PostgreSQL is a good thing. A press > release that pushes our inclusiveness as a point, is a very good thing. I'm not sure about that. I think that other products can make their own announcements on pgsql-announce; our beta announcement should be just that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Apr 26, 2016 at 8:08 PM, Josh berkus <josh@agliodbs.com> wrote: > I've created a wiki page based on the content from this thread, for > better collaboration. > > https://wiki.postgresql.org/wiki/9.6betareleasedraft > > Changes I made: > > 1. adding template content from prior beta releases > > 2. rephrasing some features to try to make them clearer to casual users > (this still needs help) > > 3. Noting that API/feature changes may still happen, because they may. > In fact, we're pretty sure that we're at least changing a few GUC names. 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; JD's last version mentioned both. You changed the description of pushdown for FDW so that it no longer talks about direct updates, just sort and join pushdown. And you changed the description of the freeze map changes so that it's wildly inaccurate. I think the last version JD posted was much better. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 04/26/2016 06:44 PM, Robert Haas wrote: > On Tue, Apr 26, 2016 at 9:19 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >> You removed the kudos to other upcoming stuff that is outside of core. I >> think that is a mistake. We are an inclusive community. Including tips to >> users about awesome stuff that uses PostgreSQL is a good thing. A press >> release that pushes our inclusiveness as a point, is a very good thing. > > I'm not sure about that. I think that other products can make their > own announcements on pgsql-announce; our beta announcement should be > just that. If it is a product, yes but I do believe (within conservative reason) that highlighting upcoming stuff shows we collaborate. Granted it should never be "the reason" for the announcement but a little enthusiastic collaboration on cool Pg utilities? Heck yeah :) Logical decoding for users, is useless without PgLogical (right now). Why wouldn't we mention it? PgAdmin is *the default* GUI admin tool and version 4 is a major milestone, why wouldn't we mention it? PgBackrest is *the* most talked about backup utility we have, why wouldn't we help invigorate that community? Sincerely, JD > -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On Tue, Apr 26, 2016 at 10:12 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > On 04/26/2016 06:44 PM, Robert Haas wrote: >> >> On Tue, Apr 26, 2016 at 9:19 PM, Joshua D. Drake <jd@commandprompt.com> >> wrote: >>> >>> You removed the kudos to other upcoming stuff that is outside of core. I >>> think that is a mistake. We are an inclusive community. Including tips to >>> users about awesome stuff that uses PostgreSQL is a good thing. A press >>> release that pushes our inclusiveness as a point, is a very good thing. >> >> >> I'm not sure about that. I think that other products can make their >> own announcements on pgsql-announce; our beta announcement should be >> just that. > > > If it is a product, yes but I do believe (within conservative reason) that > highlighting upcoming stuff shows we collaborate. Granted it should never be > "the reason" for the announcement but a little enthusiastic collaboration on > cool Pg utilities? Heck yeah :) > > Logical decoding for users, is useless without PgLogical (right now). Why > wouldn't we mention it? > > PgAdmin is *the default* GUI admin tool and version 4 is a major milestone, > why wouldn't we mention it? > > PgBackrest is *the* most talked about backup utility we have, why wouldn't > we help invigorate that community? I am not opposed to promoting those things; I just don't think it belongs in the beta announcement. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 04/26/2016 07:21 PM, Robert Haas wrote: > I am not opposed to promoting those things; I just don't think it > belongs in the beta announcement. > Fair enough. What would you suggest as an alternative? I exclusively speak to practitioners. The people doing the lifting after we release. A constant question is about tools. Heck, most of the time it isn't, "when will we support X", it is more, "what tool would help me do Y?" It seems that an announcement of a Beta is a perfect opportunity without taking away from the release itself. That said, is there something you think would be more appropriate? Do you think we should advocate a "toolset" or some such thing? I love the idea of a .Org extended toolset. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On Tue, Apr 26, 2016 at 10:37 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > On 04/26/2016 07:21 PM, Robert Haas wrote: >> I am not opposed to promoting those things; I just don't think it >> belongs in the beta announcement. > > Fair enough. > > What would you suggest as an alternative? I exclusively speak to > practitioners. The people doing the lifting after we release. A constant > question is about tools. Heck, most of the time it isn't, "when will we > support X", it is more, "what tool would help me do Y?" > > It seems that an announcement of a Beta is a perfect opportunity without > taking away from the release itself. That said, is there something you think > would be more appropriate? Do you think we should advocate a "toolset" or > some such thing? I love the idea of a .Org extended toolset. I think there's a fine line between advocating good third-party projects and undue partisanship. If we advocate a bunch of Crunchy-developed tools and no 2ndQuadrant-developed tools, or visca versa, then people at the other company may not like that very much. Never mind what might be done by EnterpriseDB, Dalibo, PG Experts, and others. If we never recommend anything, that's not good, but favoring one company over another is not good either. I don't know how to strike the right balance there, but I think that's a topic for another day. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Apr 26, 2016 at 10:46:43PM -0400, Robert Haas wrote: > I think there's a fine line between advocating good third-party > projects and undue partisanship. If we advocate a bunch of > Crunchy-developed tools and no 2ndQuadrant-developed tools, or visca > versa, then people at the other company may not like that very much. > Never mind what might be done by EnterpriseDB, Dalibo, PG Experts, and > others. If we never recommend anything, that's not good, but favoring > one company over another is not good either. I don't know how to > strike the right balance there, but I think that's a topic for another > day. I agree we need more of a tool focus, e.g. I still can't figure out the features of the various backup tools. I think it needs a wiki page or a set of blog entries to really cover the details. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Tue, Apr 26, 2016 at 11:01:16PM -0400, Bruce Momjian wrote: > On Tue, Apr 26, 2016 at 10:46:43PM -0400, Robert Haas wrote: > > I think there's a fine line between advocating good third-party > > projects and undue partisanship. If we advocate a bunch of > > Crunchy-developed tools and no 2ndQuadrant-developed tools, or visca > > versa, then people at the other company may not like that very much. > > Never mind what might be done by EnterpriseDB, Dalibo, PG Experts, and > > others. If we never recommend anything, that's not good, but favoring > > one company over another is not good either. I don't know how to > > strike the right balance there, but I think that's a topic for another > > day. > > I agree we need more of a tool focus, e.g. I still can't figure out the > features of the various backup tools. I think it needs a wiki page or a > set of blog entries to really cover the details. FYI, if we can agree on a summary I think we could add it to the official docs. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 04/26/2016 07:12 PM, Joshua D. Drake wrote: > Logical decoding for users, is useless without PgLogical (right now). > Why wouldn't we mention it? Because pglogical isn't expected to be ready by beta time. > PgAdmin is *the default* GUI admin tool and version 4 is a major > milestone, why wouldn't we mention it? It should have its own announcement. > PgBackrest is *the* most talked about backup utility we have, why > wouldn't we help invigorate that community? If it's having a major release, it should also have its own announcement. -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
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? > 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? > 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. > I think the last version JD posted was much better. It was a much better description with *you* as the target audience, yes. However, you are not very representative of the majority of our users. My goal is to provide text which will make some sense to people who haven't paid any attention to PostgreSQL development since 9.5 was released. -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
On 04/26/2016 08:42 PM, Josh berkus wrote: > On 04/26/2016 07:12 PM, Joshua D. Drake wrote: > >> Logical decoding for users, is useless without PgLogical (right now). >> Why wouldn't we mention it? > > Because pglogical isn't expected to be ready by beta time. > >> PgAdmin is *the default* GUI admin tool and version 4 is a major >> milestone, why wouldn't we mention it? > > It should have its own announcement. > >> PgBackrest is *the* most talked about backup utility we have, why >> wouldn't we help invigorate that community? > > If it's having a major release, it should also have its own announcement. > How about, reasons why? I have provided reasons why I think we should do this, all that is provided above is disagreement without reason. That isn't useful. JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 04/26/2016 08:46 PM, Josh berkus wrote: >> I think the last version JD posted was much better. > > It was a much better description with *you* as the target audience, yes. > However, you are not very representative of the majority of our users. > My goal is to provide text which will make some sense to people who > haven't paid any attention to PostgreSQL development since 9.5 was released. I don't agree with this. The version you posted shows a rather lackluster faith in our user base. Further, this is a *BETA* even if you are correct that your wording is better, the people that are going to be using/testing this version *ARE* the people who are going to research and know what those features are. Sincerely, JD > -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 04/27/2016 06:36 AM, Joshua D. Drake wrote: > On 04/26/2016 08:42 PM, Josh berkus wrote: >> On 04/26/2016 07:12 PM, Joshua D. Drake wrote: >> >>> Logical decoding for users, is useless without PgLogical (right now). >>> Why wouldn't we mention it? >> >> Because pglogical isn't expected to be ready by beta time. >> >>> PgAdmin is *the default* GUI admin tool and version 4 is a major >>> milestone, why wouldn't we mention it? >> >> It should have its own announcement. >> >>> PgBackrest is *the* most talked about backup utility we have, why >>> wouldn't we help invigorate that community? >> >> If it's having a major release, it should also have its own announcement. >> > > How about, reasons why? > > I have provided reasons why I think we should do this, all that is > provided above is disagreement without reason. That isn't useful. Reasons: 1) It is the announcement for the Postgres core project. 2) Calling out projects is the community declaring winners and I don't we should be in that game. 3) It is an announcement and most folks quit reading after the first paragraph anyway. 4) It is a Beta announcement and the fact that the code is at that stage is enough of an incentive for those that care. > > > JD > > -- Adrian Klaver adrian.klaver@aklaver.com
On 04/27/2016 07:10 AM, Adrian Klaver wrote: >> How about, reasons why? >> >> I have provided reasons why I think we should do this, all that is >> provided above is disagreement without reason. That isn't useful. > > Reasons: Thank you Adrian. I don't agree with your reasons. I think they are limited in vision and scope of what is possible if we build strong and active relationships with related communities. But... I am not the only voice in the community. If that is the communities will, so be it. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 27 Apr 2016, at 15:36, Joshua D. Drake <jd@commandprompt.com> wrote: > On 04/27/2016 07:10 AM, Adrian Klaver wrote: >>> How about, reasons why? >>> >>> I have provided reasons why I think we should do this, all that is >>> provided above is disagreement without reason. That isn't useful. >> >> Reasons: > > Thank you Adrian. > > I don't agree with your reasons. I think they are limited in vision and scope of what is possible if we build strong andactive relationships with related communities. > > But... I am not the only voice in the community. If that is the communities will, so be it. No, you're correct. We should definitely use (and borderline abuse :>) every opportunity to highlight + encourage related Community projects. We're *on their side* after all, and want them to be successful. It's not hurting us in the slightest to do that. If someone feels that's picking favourites... tough. ;) Point out the alternatives, and we can mention them in the subsequent announcements. :D + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On 04/27/2016 07:36 AM, Joshua D. Drake wrote: > On 04/27/2016 07:10 AM, Adrian Klaver wrote: > >>> How about, reasons why? >>> >>> I have provided reasons why I think we should do this, all that is >>> provided above is disagreement without reason. That isn't useful. >> >> Reasons: > > Thank you Adrian. > > I don't agree with your reasons. I think they are limited in vision and > scope of what is possible if we build strong and active relationships > with related communities. You are conflating two concepts, building a community and making a Beta announcement. The first is a long term, wide spread project. The second is a point in time notification of an event. Dragging in data extraneous to that event only muddies what the notification is about. > > But... I am not the only voice in the community. If that is the > communities will, so be it. > > Sincerely, > > JD > -- Adrian Klaver adrian.klaver@aklaver.com
On 27 Apr 2016, at 15:46, Adrian Klaver <adrian.klaver@aklaver.com> wrote: <snip> > You are conflating two concepts, building a community and making a Beta announcement. The first is a long term, wide spreadproject. The second is a point in time notification of an event. Dragging in data extraneous to that event only muddieswhat the notification is about. "only muddies" isn't true. The beta announcement also provides an opportunity to point out other Community projects. That's something that should be done as often as possible. :) + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On 04/26/2016 08:46 PM, Josh berkus wrote: > On 04/26/2016 06:49 PM, Robert Haas wrote: >> I think the last version JD posted was much better. > > It was a much better description with *you* as the target audience, yes. > However, you are not very representative of the majority of our users. > My goal is to provide text which will make some sense to people who > haven't paid any attention to PostgreSQL development since 9.5 was released. > I have been thinking about this more and I think I have a middle ground. We should include my wording or wording that is similar to mine but we should also include a link to a single page that discusses the "practitioner" version of those features. The page should be simple: Feature: * Why it is good * How to test it (if we can) Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 04/27/2016 06:36 AM, Joshua D. Drake wrote: > On 04/26/2016 08:42 PM, Josh berkus wrote: >> On 04/26/2016 07:12 PM, Joshua D. Drake wrote: >> >>> Logical decoding for users, is useless without PgLogical (right now). >>> Why wouldn't we mention it? >> >> Because pglogical isn't expected to be ready by beta time. >> >>> PgAdmin is *the default* GUI admin tool and version 4 is a major >>> milestone, why wouldn't we mention it? >> >> It should have its own announcement. >> >>> PgBackrest is *the* most talked about backup utility we have, why >>> wouldn't we help invigorate that community? >> >> If it's having a major release, it should also have its own announcement. >> > > How about, reasons why? > > I have provided reasons why I think we should do this, all that is > provided above is disagreement without reason. That isn't useful. The above supplies reasons why. The other reason is that the beta draft, including a lot of stuff we NEED to have in there, is already something like 2 pages long. There's a limit to how much we can expect people to read; a list of accessory projects having releases at the bottom wouldn't get read. If it weren't for length, I'd be all for having a list of projects which are having a release to get ready for 9.6; we've done that several times before, and that's useful for testing too. "pgAdmin has been adjusted to support X in the new release, please test". I don't know that we have anything like that, though, do we? -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
On 04/27/2016 09:40 AM, Josh berkus wrote: > If it weren't for length, I'd be all for having a list of projects which > are having a release to get ready for 9.6; we've done that several times > before, and that's useful for testing too. "pgAdmin has been adjusted > to support X in the new release, please test". I don't know that we > have anything like that, though, do we? The only thing would be PgLogical but I don't think it warrants exclusivity. JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 04/27/2016 08:48 AM, Joshua D. Drake wrote: > On 04/26/2016 08:46 PM, Josh berkus wrote: >> On 04/26/2016 06:49 PM, Robert Haas wrote: > >>> I think the last version JD posted was much better. >> >> It was a much better description with *you* as the target audience, yes. >> However, you are not very representative of the majority of our users. >> My goal is to provide text which will make some sense to people who >> haven't paid any attention to PostgreSQL development since 9.5 was >> released. >> > > I have been thinking about this more and I think I have a middle ground. > We should include my wording or wording that is similar to mine but we > should also include a link to a single page that discusses the > "practitioner" version of those features. The page should be simple: That's the typical "what's new" page, which I'll be creating soon if someone doesn't beat me to it (please leave out the apostrophe to avoid mediawiki issues, though). However, we need to have the "why this matters" in the beta annoucement itself, for two reasons: 1. our beta announcements get some press coverage, so the press needs to be able to quote the new features; 2. we want DBAs who haven't upgraded since 9.2 to get excited enough about one or more features to test them. If anything, we should have the "pithy" items in the original announcement, and links to the technical details on a wiki page, not the other way around. I'm also going to revisit the idea of only including five features. Part of the idea of the beta annoucement is to get people to test our features, and sometimes the features which need the most testing aren't the banner-carrier ones. Do we have other features which really warrant extensive testing? -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
On Wed, Apr 27, 2016 at 12:50 PM, Josh berkus <josh@agliodbs.com> wrote: > On 04/27/2016 08:48 AM, Joshua D. Drake wrote: >> On 04/26/2016 08:46 PM, Josh berkus wrote: >>> On 04/26/2016 06:49 PM, Robert Haas wrote: >> >>>> I think the last version JD posted was much better. >>> >>> It was a much better description with *you* as the target audience, yes. >>> However, you are not very representative of the majority of our users. >>> My goal is to provide text which will make some sense to people who >>> haven't paid any attention to PostgreSQL development since 9.5 was >>> released. >>> >> >> I have been thinking about this more and I think I have a middle ground. >> We should include my wording or wording that is similar to mine but we >> should also include a link to a single page that discusses the >> "practitioner" version of those features. The page should be simple: > > That's the typical "what's new" page, which I'll be creating soon if > someone doesn't beat me to it (please leave out the apostrophe to avoid > mediawiki issues, though). > > However, we need to have the "why this matters" in the beta annoucement > itself, for two reasons: > > 1. our beta announcements get some press coverage, so the press needs to > be able to quote the new features; > > 2. we want DBAs who haven't upgraded since 9.2 to get excited enough > about one or more features to test them. > > If anything, we should have the "pithy" items in the original > announcement, and links to the technical details on a wiki page, not the > other way around. > > I'm also going to revisit the idea of only including five features. > Part of the idea of the beta annoucement is to get people to test our > features, and sometimes the features which need the most testing aren't > the banner-carrier ones. Do we have other features which really warrant > extensive testing? There's a rather brilliant list (rather well-worded, too, IMHO) at https://en.wikipedia.org/wiki/PostgreSQL#Upcoming_features I believe it was curated primarily by Thom Brown. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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
* Joshua D. Drake (jd@commandprompt.com) wrote: > On 04/27/2016 09:40 AM, Josh berkus wrote: > > >If it weren't for length, I'd be all for having a list of projects which > >are having a release to get ready for 9.6; we've done that several times > >before, and that's useful for testing too. "pgAdmin has been adjusted > >to support X in the new release, please test". I don't know that we > >have anything like that, though, do we? > > The only thing would be PgLogical but I don't think it warrants exclusivity. Not entirely sure I'm following along correctly, but if we're talking about tools being updated for 9.6, it seems likley that all of the backup tools which use pg_start/stop_backup will be updated for the new API. Thanks! Stephen
Attachment
Justin Clift wrote: > On 27 Apr 2016, at 15:46, Adrian Klaver <adrian.klaver@aklaver.com> wrote: > <snip> > > You are conflating two concepts, building a community and making a Beta announcement. The first is a long term, widespread project. The second is a point in time notification of an event. Dragging in data extraneous to that event onlymuddies what the notification is about. > > "only muddies" isn't true. The beta announcement also provides an opportunity > to point out other Community projects. That's something that should be done > as often as possible. :) I think Robert said it best in http://www.postgresql.org/message-id/CA+TgmoZVBmTnUT419mS3pV9hESJh78gibD_2tviaoGMWvOTwtg@mail.gmail.com The risk of alienating other people who happens to have worked on "competing" tools is very high. I think the mere fact that this discussion is occuring should be indicative of this being a bad idea. In short, -1 from me. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi,
2016-04-28 14:06 GMT+10:00 Alvaro Herrera <alvherre@2ndquadrant.com>:
I think the mere fact that this discussion is occuring should be
indicative of this being a bad idea. In short, -1 from me.
I agree with Robert and Alvaro. While I generally think that promoting satellite projects/tools/products is strategic, I think the community should not favour any position, rather facilitate objective and super-partes promotion of such tools. This could be in the wiki or, why not, in the documentation itself.
However, I guess we need to reflect on the status of the Wiki (I blame myself too).
Cheers,
Gabriele
On 04/27/2016 01:50 PM, Stephen Frost wrote: > * Joshua D. Drake (jd@commandprompt.com) wrote: >> On 04/27/2016 09:40 AM, Josh berkus wrote: >> >>> If it weren't for length, I'd be all for having a list of projects which >>> are having a release to get ready for 9.6; we've done that several times >>> before, and that's useful for testing too. "pgAdmin has been adjusted >>> to support X in the new release, please test". I don't know that we >>> have anything like that, though, do we? >> >> The only thing would be PgLogical but I don't think it warrants exclusivity. > > Not entirely sure I'm following along correctly, but if we're talking > about tools being updated for 9.6, it seems likley that all of the > backup tools which use pg_start/stop_backup will be updated for the new > API. Damn, which means I need to test mine too. Where are these changes documented? -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
* Josh berkus (josh@agliodbs.com) wrote: > On 04/27/2016 01:50 PM, Stephen Frost wrote: > > * Joshua D. Drake (jd@commandprompt.com) wrote: > >> On 04/27/2016 09:40 AM, Josh berkus wrote: > >> > >>> If it weren't for length, I'd be all for having a list of projects which > >>> are having a release to get ready for 9.6; we've done that several times > >>> before, and that's useful for testing too. "pgAdmin has been adjusted > >>> to support X in the new release, please test". I don't know that we > >>> have anything like that, though, do we? > >> > >> The only thing would be PgLogical but I don't think it warrants exclusivity. > > > > Not entirely sure I'm following along correctly, but if we're talking > > about tools being updated for 9.6, it seems likley that all of the > > backup tools which use pg_start/stop_backup will be updated for the new > > API. > > Damn, which means I need to test mine too. Where are these changes > documented? The changes are to pg_start/stop_backup and their updated definitions can be reviewed here: http://www.postgresql.org/docs/devel/static/functions-admin.html Note that it's technically backwards compatible, however, the existing exclusive backup approach is bad and may mean that the database doesn't automatically recover from a crash which happens while the backup is running. All backup tools should be updated to the new APIs to avoid that risk. Thanks! Stephen
Attachment
On Fri, Apr 29, 2016 at 07:14:22AM -0400, Stephen Frost wrote: > > Damn, which means I need to test mine too. Where are these changes > > documented? > > The changes are to pg_start/stop_backup and their updated definitions > can be reviewed here: > > http://www.postgresql.org/docs/devel/static/functions-admin.html > > Note that it's technically backwards compatible, however, the existing > exclusive backup approach is bad and may mean that the database doesn't > automatically recover from a crash which happens while the backup is > running. All backup tools should be updated to the new APIs to avoid > that risk. Is this risk new? Is it documented? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
* Bruce Momjian (bruce@momjian.us) wrote: > On Fri, Apr 29, 2016 at 07:14:22AM -0400, Stephen Frost wrote: > > > Damn, which means I need to test mine too. Where are these changes > > > documented? > > > > The changes are to pg_start/stop_backup and their updated definitions > > can be reviewed here: > > > > http://www.postgresql.org/docs/devel/static/functions-admin.html > > > > Note that it's technically backwards compatible, however, the existing > > exclusive backup approach is bad and may mean that the database doesn't > > automatically recover from a crash which happens while the backup is > > running. All backup tools should be updated to the new APIs to avoid > > that risk. > > Is this risk new? Is it documented? No, it's not new. I'm not sure off-hand if it's documented. Thanks! Stephen
Attachment
On Fri, Apr 29, 2016 at 1:32 PM, Stephen Frost <sfrost@snowman.net> wrote:
* Bruce Momjian (bruce@momjian.us) wrote:
> On Fri, Apr 29, 2016 at 07:14:22AM -0400, Stephen Frost wrote:
> > > Damn, which means I need to test mine too. Where are these changes
> > > documented?
> >
> > The changes are to pg_start/stop_backup and their updated definitions
> > can be reviewed here:
> >
> > http://www.postgresql.org/docs/devel/static/functions-admin.html
> >
> > Note that it's technically backwards compatible, however, the existing
> > exclusive backup approach is bad and may mean that the database doesn't
> > automatically recover from a crash which happens while the backup is
> > running. All backup tools should be updated to the new APIs to avoid
> > that risk.
>
> Is this risk new? Is it documented?
No, it's not new. I'm not sure off-hand if it's documented.
It is not new.
And no it is at least not well documented. But there are other parts which aren't as well - such as the requirement to actually run pg_stop_backup() even in the case you want to abort a backup, or your next one will fail. Basically the old method is quite fragile and no, we haven't documented that properly previously.
On Fri, Apr 29, 2016 at 01:36:35PM +0200, Magnus Hagander wrote: > > > http://www.postgresql.org/docs/devel/static/functions-admin.html > > > > > > Note that it's technically backwards compatible, however, the existing > > > exclusive backup approach is bad and may mean that the database doesn't > > > automatically recover from a crash which happens while the backup is > > > running. All backup tools should be updated to the new APIs to avoid > > > that risk. > > > > Is this risk new? Is it documented? > > No, it's not new. I'm not sure off-hand if it's documented. > > > It is not new. > > And no it is at least not well documented. But there are other parts which > aren't as well - such as the requirement to actually run pg_stop_backup() even > in the case you want to abort a backup, or your next one will fail. Basically > the old method is quite fragile and no, we haven't documented that properly > previously. Well, if the API was in wide use and will be supported for several more years, we had better document it, no? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Fri, Apr 29, 2016 at 1:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Apr 29, 2016 at 01:36:35PM +0200, Magnus Hagander wrote:
> > > http://www.postgresql.org/docs/devel/static/functions-admin.html
> > >
> > > Note that it's technically backwards compatible, however, the existing
> > > exclusive backup approach is bad and may mean that the database doesn't
> > > automatically recover from a crash which happens while the backup is
> > > running. All backup tools should be updated to the new APIs to avoid
> > > that risk.
> >
> > Is this risk new? Is it documented?
>
> No, it's not new. I'm not sure off-hand if it's documented.
>
>
> It is not new.
>
> And no it is at least not well documented. But there are other parts which
> aren't as well - such as the requirement to actually run pg_stop_backup() even
> in the case you want to abort a backup, or your next one will fail. Basically
> the old method is quite fragile and no, we haven't documented that properly
> previously.
Well, if the API was in wide use and will be supported for several more
years, we had better document it, no?
Absolutely. That was part of that "bigger backup docs rewrite" that hasn't happened yet, but hopefully will before the final release.
On Fri, Apr 29, 2016 at 01:41:26PM +0200, Magnus Hagander wrote: > > > On Fri, Apr 29, 2016 at 1:38 PM, Bruce Momjian <bruce@momjian.us> wrote: > > > And no it is at least not well documented. But there are other parts > which > > aren't as well - such as the requirement to actually run pg_stop_backup() > even > > in the case you want to abort a backup, or your next one will fail. > Basically > > the old method is quite fragile and no, we haven't documented that > properly > > previously. > > Well, if the API was in wide use and will be supported for several more > years, we had better document it, no? > > > Absolutely. That was part of that "bigger backup docs rewrite" that hasn't > happened yet, but hopefully will before the final release. Well, I don't even know the details of the failures, so I can't add that information. Let's get it in there somewhere and I can move it around later. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Fri, Apr 29, 2016 at 1:42 PM, Bruce Momjian <bruce@momjian.us> wrote:
-- On Fri, Apr 29, 2016 at 01:41:26PM +0200, Magnus Hagander wrote:
>
>
> On Fri, Apr 29, 2016 at 1:38 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> > And no it is at least not well documented. But there are other parts
> which
> > aren't as well - such as the requirement to actually run pg_stop_backup()
> even
> > in the case you want to abort a backup, or your next one will fail.
> Basically
> > the old method is quite fragile and no, we haven't documented that
> properly
> > previously.
>
> Well, if the API was in wide use and will be supported for several more
> years, we had better document it, no?
>
>
> Absolutely. That was part of that "bigger backup docs rewrite" that hasn't
> happened yet, but hopefully will before the final release.
Well, I don't even know the details of the failures, so I can't add that
information. Let's get it in there somewhere and I can move it around
later.
FYI, I'm not ignoring this request, I've just been insanely busy lately. I definitely plan to get it done, but I won't make it before beta (as should be obvious by now, given the timing). My apologies.
Folks, I've incorporated the feedback on this thread into the draft. At this point, I'll consider it final. https://wiki.postgresql.org/wiki/9.6betareleasedraft -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
On 2016-05-09 22:53, Josh berkus wrote: > https://wiki.postgresql.org/wiki/9.6betareleasedraft s/release of version 9.5/release of version 9.6/ s/ the the parallelism/ the parallelism/ s/ an Beta/ a Beta/ s/This is first beta/This is the first beta/
On 05/09/2016 03:53 PM, Josh berkus wrote: > Folks, > > I've incorporated the feedback on this thread into the draft. At this > point, I'll consider it final. > > https://wiki.postgresql.org/wiki/9.6betareleasedraft I am "ok" with this except for: Full text search on phrases Just because I don't think it says what it does but I do admit I don't have better wording. > > -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 05/09/2016 04:10 PM, Erik Rijkers wrote: > On 2016-05-09 22:53, Josh berkus wrote: > >> https://wiki.postgresql.org/wiki/9.6betareleasedraft > > > s/release of version 9.5/release of version 9.6/ > s/ the the parallelism/ the parallelism/ > s/ an Beta/ a Beta/ > s/This is first beta/This is the first beta/ Thanks for edits! -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
On 05/09/2016 04:19 PM, Josh berkus wrote: > On 05/09/2016 04:10 PM, Erik Rijkers wrote: >> On 2016-05-09 22:53, Josh berkus wrote: >> >>> https://wiki.postgresql.org/wiki/9.6betareleasedraft >> >> >> s/release of version 9.5/release of version 9.6/ >> s/ the the parallelism/ the parallelism/ >> s/ an Beta/ a Beta/ >> s/This is first beta/This is the first beta/ > > Thanks for edits! > On further inspection: * postgres_fdw pushes down sorts, joins, UPDATEs and DELETEs, enhancing federated database support How about: * postgres_fdw now optimized for sorts, joins, UPDATEs and DELETEs, enhancing federated database support "pushes down" means pretty much nothing to the layman. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 05/09/2016 04:31 PM, Joshua D. Drake wrote: > On 05/09/2016 04:19 PM, Josh berkus wrote: >> On 05/09/2016 04:10 PM, Erik Rijkers wrote: >>> On 2016-05-09 22:53, Josh berkus wrote: >>> >>>> https://wiki.postgresql.org/wiki/9.6betareleasedraft >>> >>> >>> s/release of version 9.5/release of version 9.6/ >>> s/ the the parallelism/ the parallelism/ >>> s/ an Beta/ a Beta/ >>> s/This is first beta/This is the first beta/ >> >> Thanks for edits! >> > > On further inspection: > > * postgres_fdw pushes down sorts, joins, UPDATEs and DELETEs, enhancing > federated database support > > How about: > > * postgres_fdw now optimized for sorts, joins, UPDATEs and DELETEs, > enhancing federated database support > > "pushes down" means pretty much nothing to the layman. Hmmm. Not sure I agree. "optimizes" is also pretty vague. Optimizes how? -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
On 05/09/2016 04:32 PM, Josh berkus wrote: > On 05/09/2016 04:31 PM, Joshua D. Drake wrote: >> On 05/09/2016 04:19 PM, Josh berkus wrote: >> On further inspection: >> >> * postgres_fdw pushes down sorts, joins, UPDATEs and DELETEs, enhancing >> federated database support >> >> How about: >> >> * postgres_fdw now optimized for sorts, joins, UPDATEs and DELETEs, >> enhancing federated database support >> >> "pushes down" means pretty much nothing to the layman. > > Hmmm. Not sure I agree. "optimizes" is also pretty vague. Optimizes how? I agree that optimizes is vague but it at least insinuates a positive or performance based outcome. "Pushes down" means what? Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 05/09/2016 04:42 PM, Joshua D. Drake wrote: > On 05/09/2016 04:32 PM, Josh berkus wrote: >> On 05/09/2016 04:31 PM, Joshua D. Drake wrote: >>> On 05/09/2016 04:19 PM, Josh berkus wrote: > >>> On further inspection: >>> >>> * postgres_fdw pushes down sorts, joins, UPDATEs and DELETEs, enhancing >>> federated database support >>> >>> How about: >>> >>> * postgres_fdw now optimized for sorts, joins, UPDATEs and DELETEs, >>> enhancing federated database support >>> >>> "pushes down" means pretty much nothing to the layman. >> >> Hmmm. Not sure I agree. "optimizes" is also pretty vague. Optimizes >> how? > > I agree that optimizes is vague but it at least insinuates a positive or > performance based outcome. "Pushes down" means what? Point, although we use the phrase a lot elsewhere. Really "remote execution" might be better, but we don't really use those words anywhere else ... Ideas, anyone else? -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
On 05/09/2016 04:45 PM, Josh berkus wrote: > On 05/09/2016 04:42 PM, Joshua D. Drake wrote: >> On 05/09/2016 04:32 PM, Josh berkus wrote: >>> On 05/09/2016 04:31 PM, Joshua D. Drake wrote: >>>> On 05/09/2016 04:19 PM, Josh berkus wrote: >> I agree that optimizes is vague but it at least insinuates a positive or >> performance based outcome. "Pushes down" means what? > > Point, although we use the phrase a lot elsewhere. Really "remote > execution" might be better, but we don't really use those words anywhere > else ... Ehh, it isn't really remote execution either though.... > > Ideas, anyone else? > * postgres_fdw optimized with remote planner support for sorts, joins, UPDATEs and DELETEs, enhancing federated database support ?? Sincerely, JD > -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 05/09/2016 04:42 PM, Joshua D. Drake wrote:
> On 05/09/2016 04:32 PM, Josh berkus wrote:
>> On 05/09/2016 04:31 PM, Joshua D. Drake wrote:
>>> On 05/09/2016 04:19 PM, Josh berkus wrote:
>
>>> On further inspection:
>>>
>>> * postgres_fdw pushes down sorts, joins, UPDATEs and DELETEs, enhancing
>>> federated database support
>>>
>>> How about:
>>>
>>> * postgres_fdw now optimized for sorts, joins, UPDATEs and DELETEs,
>>> enhancing federated database support
>>>
>>> "pushes down" means pretty much nothing to the layman.
>>
>> Hmmm. Not sure I agree. "optimizes" is also pretty vague. Optimizes
>> how?
>
> I agree that optimizes is vague but it at least insinuates a positive or
> performance based outcome. "Pushes down" means what?
Point, although we use the phrase a lot elsewhere. Really "remote
execution" might be better, but we don't really use those words anywhere
else ...
postgres_fdw now executes sorts, joins, updates, and deletes on the remote server.
Though sort/join seems to be a different class than update/delete; possibly warranting two sentences.
Enhanced federated database support via postgres_fdw: you can now execute updates and deletes on the remote server. Furthermore, sorts and joins are now executed remotely, reducing data transfer and improving speed.
Though, for me, "push down" is lot less cumbersome than "enhancing federated database support"
The later sounds more geek than the former.
I could be a bit off as I haven't really delved into the feature. But I suspect any inaccuracy would be a fair trade for simplicity in this non-technical document.
David J.
On 05/09/2016 05:00 PM, David G. Johnston wrote: > postgres_fdw now executes sorts, joins, updates, and deletes on the > remote server. * postgres_fdw can now execute sorts, joins, UPDATEs and DELETEs on the remote server Thanks! -- -- Josh Berkus Red Hat OSAS (any opinions are my own)