From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Adam Brusselback <adambrusselback(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimizer items in the release notes |
Date: | 2019-04-27 02:22:26 |
Message-ID: | 20190427022226.lenmekhcrllgb2ow@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Apr 27, 2019 at 02:04:33PM +1200, David Rowley wrote:
> On Sat, 27 Apr 2019 at 11:49, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >
> > On Wed, Apr 24, 2019 at 02:46:15PM -0400, Adam Brusselback wrote:
> > > As a user, I am interested in the optimizer changes for sure, and I
> > > actually had wished they were highlighted more in previous releases.
> > >
> > > > I think planner smarts are arguably one of our weakest areas when
> > > > compared to the big commercial databases. The more we can throw in
> > > > there about this sort of thing the better.
> > >
> > > Completely agree on both fronts. I have run into numerous
> > > optimizations I had taken for granted when I worked primarily with SQL
> > > Server and were not present in Postgres. Work being done to make the
> > > Postgres optimizer smarter is great, as is highlighting that work in
> > > the release notes IMO.
> >
> > This thread highlights the challenges of having optimizer items in the
> > release notes:
> >
> > * They often reply to only a small percentage of queries
>
> That can often be true, but as I mentioned that it's quite common that
> the queries that the changes do effect see massive performance
> improvements. Some patch that gave us 5% across the board is unlikely
> to unblock someone from migrating to PostgreSQL, but some query
> planner smarts that reduce query times by orders of magnitude could
> unblock someone.
The problem is that it is rare, and hard to explain, so it is almost
impossible for an average user to have any hope in guessing if it will
help them.
> > * They are hard to explain
>
> That can be true, but we generally get there if not the first time
> then after a few iterations. Authors and committers of the
> improvements are likely to be able to help find suitable wording.
It is not the text that is hard, but hard to explain the concept in a
way that relates to anything a normal user is familiar with.
> > I see the argument as wanting vague warm and fuzzy feelings that we are
> > improving the optimizer, which we are.
>
> Not sure where the warm and fuzzy argument is from. The point I tried
> to make was that if we're making changes to PostgreSQL that are likely
> going to be useful to people, then we likely should put them in the
> release notes. It was my understanding that this was why major version
> release notes were useful.
It is for generally-common user behavior changes. If we just repeat the
commit logs, it will we much less readable.
> > I will see what I can do to get
> > those ideas into the PG 12 release notes in as concrete a way as
> > possible.
>
> I think the current process is really good. You take on the hard task
> of drafting them up, to which everyone is very grateful for as it's a
> pretty tedious job. Various people that might have been closer to the
> actual work done for certain items then suggest improvements.
Yes, that has been the plan.
--
Bruce Momjian <bruce(at)momjian(dot)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 +
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-04-27 02:47:44 | Re: Optimizer items in the release notes |
Previous Message | David Rowley | 2019-04-27 02:04:33 | Re: Optimizer items in the release notes |