Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hRRk7-0007bR-Tv for pgsql-advocacy@arkaria.postgresql.org; Fri, 17 May 2019 01:33:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hRRk6-0003Ld-Gc for pgsql-advocacy@arkaria.postgresql.org; Fri, 17 May 2019 01:33:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hRRk6-0003Jw-4s for pgsql-advocacy@lists.postgresql.org; Fri, 17 May 2019 01:33:02 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hRRk3-0006ag-M0; Fri, 17 May 2019 01:33:00 +0000 Received: from bruce by momjian.us with local (Exim 4.89) (envelope-from ) id 1hRRjz-0003Sz-Ob; Thu, 16 May 2019 21:32:55 -0400 Date: Thu, 16 May 2019 21:32:55 -0400 From: Bruce Momjian To: Peter Geoghegan Cc: Michael Paquier , Alvaro Herrera , Amit Langote , David Rowley , "Jonathan S. Katz" , PostgreSQL Advocacy Subject: Re: PostgreSQL 12: Feature Highlights Message-ID: <20190517013255.bera5dtuii376lae@momjian.us> References: <20190516182628.kbkiajfnlooocgyg@momjian.us> <20190516190806.GA14121@alvherre.pgsql> <20190516235250.GD20887@paquier.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, May 16, 2019 at 05:05:13PM -0700, Peter Geoghegan wrote: > On Thu, May 16, 2019 at 4:52 PM Michael Paquier wrote: > > +1. Another thing which may matter is that if some people do not see > > some improvements they were expecting then they can come back to pg13 > > and help around with having these added. Things are never going to be > > perfect for all users, and it makes little sense to make it sound like > > things are actually perfect. > > Speaking of imperfections: it is well known that most performance > enhancements have the potential to hurt certain workloads in order to > help others. Maybe that was explicitly considered to be a good > trade-off when the feature went in, and maybe that was the right > decision at the time, but more often it was something that was simply > overlooked. There is value in leaving information that helps users > discover where a problem may have been introduced -- they can tell us > about it, and we can fix it. > > I myself sometimes look through the release notes in an effort to spot > something that might have had undesirable side-effects, especially in > areas of the code that I am less knowledgeable about, or have only a > vague recollection of. Sometimes that is a reasonable starting point. The release notes are written for the _average_ reader. The commits are there as comments and making them more visible would be a nice improvement. We have already adjusted the partition item, and the btree item. If there is more detail people want, I suggest you post something to the hackers list and we will see if can be added in a consistent way. You must also get agreement that the rules I am using need to be adjusted so all future release notes will have that consistency. -- Bruce Momjian 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 +