Thread: postgres feature matrix
Hi, I was curious about how this is maintained ? https://www.postgresql.org/about/featurematrix/ I imagine someone extracts most significant stuff from the release notes? I'm not able to find this one: https://www.postgresql.org/docs/12/release-12.html |Allow partition elimination during query execution (David Rowley, Beena Emerson) |Previously, partition elimination only happened at planning time, meaning many joins and prepared queries could not usepartition elimination. https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=499be013de65242235ebdde06adb08db887f0ea5 Also, it'd be nice if the author's names were included at these pages: https://www.postgresql.org/about/featurematrix/detail/249/ It'd be nice too if there were a page indexed by author listing major contributions. Maybe for major contributors that would be visible here: https://www.postgresql.org/community/contributors/ Justin
On 2/10/20 12:03 PM, Justin Pryzby wrote: > Hi, > > I was curious about how this is maintained ? > https://www.postgresql.org/about/featurematrix/ > > I imagine someone extracts most significant stuff from the release notes? *waves* Here has been the process over the past few years: 1. First, I do some "cleaning" / consolidation based on the current state of the feature matrix. For example, before the PostgreSQL 11 release, I did some heavy reorganizing / recategorization based on the current state of PostgreSQL to try to make it more readable and easier to navigate. One of the bigger changes introduced was, by default, listing out all features, instead of just the differences between the latest 5-6 supported releases. 2. I typically wait until late in the beta period before doing a full sweep of the release notes, to know exactly what is making it in or not for the final release. I do try to add some of the features on-or-around the initial beta to drive awareness, but the usability of the features is typically better understood as the beta period progresses (and even moreso after release). The impact of certain features becomes apparent after the release, in which case they can subsequently be added. For instance, the B-tree index performance improvements in PG12 are certainly impactful, but tough to put into the feature matrix. You could point out that it appears such things may exist in the list, which is a product of having the feature matrix around for awhile (and hence why I try to continually prune/reorganize :) This leads to: > I'm not able to find this one: > https://www.postgresql.org/docs/12/release-12.html > |Allow partition elimination during query execution (David Rowley, Beena Emerson) > |Previously, partition elimination only happened at planning time, meaning many joins and prepared queries could not usepartition elimination. > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=499be013de65242235ebdde06adb08db887f0ea5 Yeah, this is an awesome contribution, and was one of the major features highlighted in the release notes and press release. When I first looked at it, this one was a bit tricky to figure out in the feature matrix, i.e. what does it mean for other performance enhancements that are added in? As mentioned, we've tried to stick to specific features we can point at on the feature matrix vs. general improvements. However, looking at this again, I think the key "feature" to point out is that partition elimination can occur during query execution. But, what does that mean to most users? That's a tricky question :) That said, I'll take a whirl at giving partition pruning it's due in the feature matrix and hope to have something up shortly. > Also, it'd be nice if the author's names were included at these pages: > https://www.postgresql.org/about/featurematrix/detail/249/ This is not a bad idea, however we would need to ensure this is applied consistently. The original (and still used) feature matrix code allows you to pass in a URL directly to the documentation directly, which, if present, brings the user directly to the documentation. The authors of features in that regard would not be recognized, unless we remove that functionality. Additionally, while I wholly support the effort of patch authors (for fairly obvious reasons :) the feature matrix may not be the best place for that. The typical user coming to the feature matrix is trying to get a better understanding of what PostgreSQL offers; the returning user is trying to understand the differences between the major versions when making the calculus to upgrade. My personal preference would be your below suggestion: > > It'd be nice too if there were a page indexed by author listing major > contributions. Maybe for major contributors that would be visible here: > https://www.postgresql.org/community/contributors/ IIRC Alvaro Herrera made a change in the documentation that would allow us to do this automatically, and we need to incorporate this into pgweb. Thanks, Jonathan
Attachment
On Mon, Feb 10, 2020 at 12:22:38PM -0500, Jonathan S. Katz wrote: > > Also, it'd be nice if the author's names were included at these pages: > > https://www.postgresql.org/about/featurematrix/detail/249/ > This is not a bad idea, however we would need to ensure this is applied > consistently. The original (and still used) feature matrix code allows > you to pass in a URL directly to the documentation directly, which, if > present, brings the user directly to the documentation. The authors of > features in that regard would not be recognized, unless we remove that > functionality. Or unless author's were stored separately from the link. But I agree there doesn't seem to be a good place to display that, which makes it pointless, especially if it's available somewhere else. > Additionally, while I wholly support the effort of patch authors (for > fairly obvious reasons :) the feature matrix may not be the best place > for that. The typical user coming to the feature matrix is trying to get > a better understanding of what PostgreSQL offers; the returning user is > trying to understand the differences between the major versions when > making the calculus to upgrade. FWIW, I was going to link to the feature matrix just now in a conversation on the -perform list regarding partition pruning, rather than make up my own description of the patch. Also, it would be sometimes useful to have <a>(nchor) tags for each item: https://www.postgresql.org/docs/11/release-11.html I wonder what it would take to make GIT hashes visible in the HTML (probably as an HTML comment). Thanks, Justin
On 2/10/20 12:39 PM, Justin Pryzby wrote: >> Additionally, while I wholly support the effort of patch authors (for >> fairly obvious reasons :) the feature matrix may not be the best place >> for that. The typical user coming to the feature matrix is trying to get >> a better understanding of what PostgreSQL offers; the returning user is >> trying to understand the differences between the major versions when >> making the calculus to upgrade. > > FWIW, I was going to link to the feature matrix just now in a conversation on > the -perform list regarding partition pruning, rather than make up my own > description of the patch. Please feel free to use my own made up description of the patch: https://www.postgresql.org/about/featurematrix/detail/332/ Interestingly, after my whole analysis above, I found was I able to codify the PG12 enhancements into the performance area earlier, which i had missed given the still large size of the "performance" category: https://www.postgresql.org/about/featurematrix/detail/320/ which now reviewing the titles of both sections, it seems like it needs a tweak, but perhaps after the next holistic review of the feature matrix and during a week that's not release week :) > Also, it would be sometimes useful to have <a>(nchor) tags for each item: > https://www.postgresql.org/docs/11/release-11.html > > I wonder what it would take to make GIT hashes visible in the HTML (probably as > an HTML comment). IIRC believe this is what Alvaro's change enabled, and it is on the ever growing backlog, which per some sidebars, I'm aiming to start tackling my bits in the near future. Thanks, Jonathan
Attachment
I want to say that I think the feature matrix is itself a neat feature, and I wonder if it should have slightly more visibility. Like a link from the main page, maybe alongside "Latest Releases", or at least referenced from: https://www.postgresql.org/support/versioning/ -- Justin
On Mon, Feb 10, 2020 at 12:53:49PM -0500, Jonathan S. Katz wrote: > Please feel free to use my own made up description of the patch: > > https://www.postgresql.org/about/featurematrix/detail/332/ .. > https://www.postgresql.org/about/featurematrix/detail/320/ It seems to me these would more naturally live under "Partitioning" rather than the oversized "performance". Also, regarding the item named "Table partitioning", it seems to me that's unclear/ambiguous/misleading. It's probably been there since pre-v10, and so it's referring to any type of table heirarchy/inheritance. I think it should be renamed, or just removed. Note commit 0c06534bd6, which is semi-relevant. Quoting my description: | I made changes to avoid "partition" (which I think should mean a child of | relkind='p', and itself of relkind='r') and "partitioned" (meaning relkind='p' | itself) but left alone most instances of "partitioning". -- Justin