Re: Postgres 11 release notes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Postgres 11 release notes
Date
Msg-id 20180511190410.ka3b5a5wvuwyzhcv@alap3.anarazel.de
Whole thread Raw
In response to Re: Postgres 11 release notes  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Postgres 11 release notes  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On 2018-05-11 14:59:04 -0400, Bruce Momjian wrote:
> On Fri, May 11, 2018 at 11:50:51AM -0700, Andres Freund wrote:
> > On 2018-05-11 14:44:06 -0400, Bruce Momjian wrote:
> > > On Fri, May 11, 2018 at 07:49:50PM +0300, Teodor Sigaev wrote:
> > > > 
> > > > 
> > > > Bruce Momjian wrote:
> > > > >I have committed the first draft of the Postgres 11 release notes.  I
> > > > >will add more markup soon.  You can view the most current version here:
> > > > >
> > > > >    http://momjian.us/pgsql_docs/release-11.html
> > > > >
> > > > >I expect a torrent of feedback.  ;-)
> > > > Hi!
> > > > 
> > > > Seems, you miss:
> > > > 857f9c36cda520030381bd8c2af20adf0ce0e1d4 Skip full index scan during cleanup
> > > > of B-tree indexes when possible
> > > 
> > > I read that and thought it was too details to be in the release notes. 
> > > It is not that it is unimportant, but it is hard to see how people would
> > > notice the difference or change their behavior based on this change.
> > 
> > It's a *huge* performance problem in larger installations
> > currently. When you have a multi-TB relation and correspondingly large
> > relation, the VM allows to make the heap cleanups cheap, but then the
> > index scan takes just about forever.  I know at least one large PG user
> > that moved off postgres because of it.  This won't solve all of those
> > concerns, but it definitely is crucial to know for such users.
> > 
> > People would notice by vacuums of large relations not taking forever
> > anymore. And the behaviour change would be to a) upgrade b) tune the
> > associated reloption/GUC.
> 
> OK, so what is the text that people will understand?  This?
> 
>     Prevent manual VACUUMs on append-only tables from performing
>     needless index scans

I don't think the table being 'append-only' is necessary?  Nor does it
have to be a manual vacuum. And 'needless index scan' sounds less than
it is/was, namely a full scan of the index. Perhaps something like:

  Allow vacuum to skip doing a full scan of btree indexes after VACUUM,
  if not necessary.

or something like that?


> You can see why I was hesitant to include it, based on this text, but I
> am happy to add it.

I can't. Even if the above were accurate it'd be relevant information.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Postgres 11 release notes
Next
From: Bruce Momjian
Date:
Subject: Re: Postgres 11 release notes