Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1smHTn-004YTl-Sp for pgsql-advocacy@arkaria.postgresql.org; Thu, 05 Sep 2024 18:45:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1smHTk-00Fg7Z-Jg for pgsql-advocacy@arkaria.postgresql.org; Thu, 05 Sep 2024 18:45:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1smHTk-00Fg7M-0U for pgsql-advocacy@lists.postgresql.org; Thu, 05 Sep 2024 18:45:12 +0000 Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1smHTf-000Juk-60 for pgsql-advocacy@lists.postgresql.org; Thu, 05 Sep 2024 18:45:11 +0000 Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3df0dc53ec1so771662b6e.1 for ; Thu, 05 Sep 2024 11:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725561906; x=1726166706; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LQl6KD9NTglrjJpOr+UVaL9d0M1Td5b4QNMRu774gPM=; b=EyijzUTpvX4SDVMvXtfGRa+rAtuo358zHQYw05csLGKfyJsD/vuHg/cwACPr/dl1zs nlI3rZcakYxhAap45KbA8UwMtImiWJzPw6ke7Xni3ehzcchE3ba14G8gWglTc9Wq8Zsw rcAffN1erKDtt2gpVS8+jIy7d2BV9RrH9YlAxd1NgYgwY3k6TEneDIX1tEZYHFeeOoGK /ee8RhXSwACJPjYUEkLk38o+3bS0LssWEm4jXMs21sAQEE0MU7GC90lkEouhgPXBiRq0 9H2gF44neuYuGP0c/72qiMH1hRLVQQ1WsONwMJslrsH36A3kPm0oB3JJhrqIEGNkHHVR CdvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725561906; x=1726166706; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LQl6KD9NTglrjJpOr+UVaL9d0M1Td5b4QNMRu774gPM=; b=CHr5VHc/Zwd5w476IZf0fhGgcP7Kw2meALStQH6QMODe78k4li5que05USMdrlonEi /I2f/H6f0icq6HCArusRRx+VtT/CG9QLHejaWhxt0nPTnnRfkx0QFHxeu+k5NiK6Vzkt z4LPAJoLHVr2qaeS+K5uChRx6B8ixEJeMdD3sVw8bDe3WwRxWwXOcKFtC0lS7y+LPw+D hiTUZYIwAN17bJ8LI/jr0T/8j911G/g+qnBp4rxtB13AXIDvgtT9eP+2plVmVQ8EtzH7 m1RO5F9d0dgCiVrMov+N95F7uTcXH1LnsU+BnLwkeGOKo/PidgYA7/9zf7QHkPTwRQlr ZPHQ== X-Forwarded-Encrypted: i=1; AJvYcCUm6UktNPwNUqpqoNUdcRhofTqaDMjMfE0XQYEshR+Cc4spVAvBhmhKai175/nYkgENGAKMdNk+CktzLCd8Rw==@lists.postgresql.org X-Gm-Message-State: AOJu0YxHI6+kBmTXPjGkaTjI8FpdVeH7lwqxZK34O7ntJ7eP3ZWvQjkb QyNmuYnv0xRLwFBQ86kJmdscaZRVtWlSvhBMMZGQH+mRHqDvqCw+O2EIGjTujAUgHCIJPgRO0C7 48gsBrfAd3GZoPgb1mkgJilhRvJQ= X-Google-Smtp-Source: AGHT+IErF8zjbm48ssnP0ahxc2us4Mw0/I9ZW1YJPwwiQpRWR/M/sLssxp5cme+BQ/70ZlPCX1N3fylef3oktmZ+Msw= X-Received: by 2002:a05:6808:1a16:b0:3d6:317b:a95c with SMTP id 5614622812f47-3e029f2184dmr339291b6e.38.1725561906382; Thu, 05 Sep 2024 11:45:06 -0700 (PDT) MIME-Version: 1.0 References: <81af1d33-1abb-4ddf-a7e9-859db718281c@postgresql.org> <906be4b7-9066-43db-8047-d34d85dff3ad@eisentraut.org> In-Reply-To: From: Andrew Atkinson Date: Thu, 5 Sep 2024 13:44:30 -0500 Message-ID: Subject: Re: PostgreSQL 17 release announcement draft To: Robert Haas Cc: Peter Eisentraut , "Jonathan S. Katz" , PostgreSQL Advocacy Content-Type: multipart/alternative; boundary="00000000000077cecd062163b02a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000077cecd062163b02a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Additional chunk: Proposed: PostgreSQL 17 improves the performance of queries with `IN` clauses that use [B-tree]( https://www.postgresql.org/docs/17/indexes-types.html#INDEXES-TYPES-BTREE) indexes, the default index method in PostgreSQL). Support for parallel index builds were added for [BRIN]( https://www.postgresql.org/docs/17/brin.html) indexing. PostgreSQL 17 leverages the constraints you've defined. The query planner removes redundant `IS NOT NULL` statements when a column has a `NOT NULL` constraint, and skips over `IS NULL` clauses for columns with an `IS NOT NULL` constraint. On Thu, Sep 5, 2024 at 11:58=E2=80=AFAM Andrew Atkinson wrote: > The write operations seem to be under-sold here! These seem very exciting > and would be beneficial to all Postgres databases I've worked on. > > Is this a fair way to reduce the three items mentioned, as much as > possible? I'm not proposing they change, but just sort of pushing on > building down the items tied to their benefit to the end user as much as > possible. Possibly shortening them and making them punchier will help. > > Faster Write throughput: > - "Fewer WAL locks shorter lock lengths" (check this, I'm making it up, > but I'm wondering if it's fewer WAL locks, or the locks are held for less > time), thus better throughput > - "Faster Sequential scans" - is the benefit that they're faster? > - "Faster ANALYZE" - is it that ANALYZE runs faster on 17 vs. the same > operation on 16? > > The last point "Allowing extensions to be integrated further." I didn't > grab on to as much. I'm wondering if it's something like "new write > operation APIs are now available for extension creators" or something lik= e > that? > > On Thu, Sep 5, 2024 at 11:49=E2=80=AFAM Andrew Atkinson > wrote: > >> Hi Jonathan. Do you want change proposals here as text snippets in >> emails? It seems the patch process isn't used here. >> >> If so, here's an attempted reduction that echoes what Robert said. I als= o >> thought explaining Vacuum wouldn't be necessary for this audience, so le= ss >> lead-in could work. Is the benefit to end users that there is less memor= y >> and CPU needed by vacuum, thus more CPU and memory is available to their >> foreground workload? >> >> Original: >> > A foundational feature of PostgreSQL is [vacuum]( >> https://www.postgresql.org/docs/17/routine-vacuuming.html), which is >> used to reclaim storage from data that was marked as removed. Reducing >> resources required for vacuuming directly helps other areas of PostgreSQ= L, >> particularly on very busy systems. PostgreSQL 17 introduces a new intern= al >> memory structure for vacuum that's shown up to a 20x reduction in memory >> and improvements in overall vacuuming speed. >> >> Proposed: >> The PostgreSQL [vacuum]( >> https://www.postgresql.org/docs/17/routine-vacuuming.html) process is >> critical for healthy operations, requiring server instance resources to >> operate. With PostgreSQL 17, a new internal memory structure for vacuum = was >> used that consumes up to 20x less memory. This improves vacuum speed and >> also reduces the use of shared resources, making more available for your >> workload. >> >> >> Something along those lines, where the benefit to the user is they could >> expect more CPU/mem etc. available for their SQL operations, right? Thi= s >> could be something folks want to benchmark as well as a reason to upgrad= e, >> at least for Vacuum-intensive workloads, high UPDATE and DELETE operatio= ns >> etc. >> >> >> >> >> >> On Thu, Sep 5, 2024 at 11:04=E2=80=AFAM Robert Haas >> wrote: >> >>> On Thu, Sep 5, 2024 at 5:22=E2=80=AFAM Peter Eisentraut >>> wrote: >>> > On 04.09.24 23:05, Jonathan S. Katz wrote: >>> > > Attached is the draft of the PostgreSQL 17 release announcement. >>> This is >>> > > a draft of the text that will go into the press kit, with the key >>> > > portions to review starting from the top of the document, up until >>> the >>> > > "About PostgreSQL" section. >>> > >>> > I noticed that we don't yet have a list of major features in the PG17 >>> > release notes. We should probably put that in soon, so that what we >>> > list there and what is in the announcement are consistent. >>> >>> +1. >>> >>> > On the actual list, there will be lots of opinions to be had, but I'l= l >>> > just offer one: I don't think the MERGE RETURNING clause deserves >>> twice >>> > as much space as incremental backup. >>> >>> I agree with that, although obviously I'm biased. >>> >>> I also feel like this whole thing could just be shorter. If it were >>> half as long and mentioned fewer things and those more briefly, would >>> we be worse off? I think we might be better off, because it just feels >>> wordy to me right now. For example: >>> >>> A foundational feature of PostgreSQL is >>> [vacuum](https://www.postgresql.org/docs/17/routine-vacuuming.html), >>> which is used to reclaim storage from data that was marked as removed. >>> Reducing resources required for vacuuming directly helps other areas >>> of PostgreSQL, particularly on very busy systems. PostgreSQL 17 >>> introduces a new internal memory structure for vacuum that's shown up >>> to a 20x reduction in memory and improvements in overall vacuuming >>> speed. This release also removes the `1GB` limit on the memory it can >>> use (controlled by >>> [`maintenance_work_mem`]( >>> https://www.postgresql.org/docs/17/runtime-config-resource.html#GUC-MAI= NTENANCE-WORK-MEM) >>> ), >>> letting users apply more resources to vacuuming, which is beneficial >>> for systems with lots of changes. >>> >>> It seems to me that the first two sentences could just be completely >>> nuked, and everything from "letting users" to the end could also be >>> nuked. At least to me, all of that stuff reads as unnecessarily >>> filler. I'm not at all sure that removing the 1GB limit on >>> maintenance_work_mem is important enough that it needs to be in the >>> release announcement -- I agree it's a good improvement, but to have >>> it be one of the first things in the press release seems like an odd >>> choice from my perspective. Nobody's going to look back on this >>> release years from now and say "oh, that was the release where could >>> finally set maintenance_work_mem=3D4GB, that was so much better". If >>> they think about VACUUM, they'll think about the 20x memory reduction >>> stuff which made the ability to configure values larger than 1GB >>> irrelevant in the first place. So I'd probably delete the part about >>> lifting the 1GB cap entirely. But even if you don't do that, the >>> paragraph could be half as long without losing anything, from my >>> perspective. >>> >>> -- >>> Robert Haas >>> EDB: http://www.enterprisedb.com >>> >>> >>> --00000000000077cecd062163b02a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Additional chunk:

Proposed:PostgreSQL 17 improves the performance of q= ueries with `IN` clauses that use [B-tree](https://www.postgresq= l.org/docs/17/indexes-types.html#INDEXES-TYPES-BTREE) indexes, the defa= ult index method in PostgreSQL). Support for parallel index builds were add= ed for [BRIN](http= s://www.postgresql.org/docs/17/brin.html) indexing.

PostgreSQL 17 levera= ges the constraints you've defined. The query planner removes redundant= `IS NOT NULL` statements when a column has a `NOT NULL` constraint, and sk= ips over `IS NULL` clauses for columns with an `IS NOT NULL` constraint.


On Thu, Sep 5, 2024 at 11:58=E2= =80=AFAM Andrew Atkinson <andy= atkinson@gmail.com> wrote:
The write operations seem to be under-s= old here! These seem very exciting and would be beneficial to all Postgres = databases I've worked on.

Is this a fair way to redu= ce the three items mentioned, as much as possible? I'm not proposing th= ey change, but just sort of pushing on building=C2=A0down the items tied to= their benefit to the end user as much as possible. Possibly shortening the= m and making them punchier will help.

Faster Write= throughput:
- "Fewer WAL locks shorter lock lengths" (= check this, I'm making it up, but I'm wondering if it's fewer W= AL locks, or the locks are held for less time), thus better throughput
- "Faster Sequential scans" =C2=A0- is the benefit that the= y're faster?
- "Faster ANALYZE" =C2=A0- is it that = ANALYZE runs faster on 17 vs. the same operation on 16?

The last point "Allowing extensions to be integrated further.&qu= ot; I didn't grab on to as much. I'm wondering if it's somethin= g like "new write operation APIs are now available for extension creat= ors" or something like that?

On Thu, Sep 5, 2024 at 11:49= =E2=80=AFAM Andrew Atkinson <andyatkinson@gmail.com> wrote:
Hi Jonathan. Do you want change pro= posals here as text snippets in emails? It seems the=C2=A0patch process isn= 't used here.

If so, here's an attempted reducti= on that echoes what Robert said. I also thought explaining Vacuum wouldn= 9;t be necessary for this audience, so less lead-in could work. Is the=C2= =A0benefit to end users that there is less memory and CPU needed by vacuum,= thus more CPU and memory is available=C2=A0to their foreground=C2=A0worklo= ad?

Original:
> A foundational feature of PostgreSQL is [vacuum](http= s://www.postgresql.org/docs/17/routine-vacuuming.html), which is used t= o reclaim storage from data that was marked as removed. Reducing resources = required for vacuuming directly helps other areas of PostgreSQL, particular= ly on very busy systems. PostgreSQL 17 introduces a new internal memory str= ucture for vacuum that's shown up to a 20x reduction in memory and impr= ovements in overall vacuuming speed.
Proposed:
The PostgreSQL [vacuum](https://www.postgresql.org/docs/1= 7/routine-vacuuming.html) process is critical for healthy operations, r= equiring server instance resources to operate. With PostgreSQL 17, a new in= ternal memory structure for vacuum was used that consumes up to 20x less me= mory. This improves vacuum speed and also=C2=A0reduces the use of shared re= sources,=C2=A0making more available for your workload.


Something along those lines, where the benefit to th= e user is they could expect more CPU/mem etc. available for their SQL opera= tions, right?=C2=A0 This could be something folks want to benchmark as well= as a reason to upgrade, at least for Vacuum-intensive workloads,=C2=A0high= UPDATE and DELETE operations etc.


=


On Thu, Sep 5, 2024 at 11:04=E2=80=AFAM Robert Haa= s <robertmhaa= s@gmail.com> wrote:
On Thu, Sep 5, 2024 at= 5:22=E2=80=AFAM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 04.09.24 23:05, Jonathan S. Katz wrote:
> > Attached is the draft of the PostgreSQL 17 release announcement. = This is
> > a draft of the text that will go into the press kit, with the key=
> > portions to review starting from the top of the document, up unti= l the
> > "About PostgreSQL" section.
>
> I noticed that we don't yet have a list of major features in the P= G17
> release notes.=C2=A0 We should probably put that in soon, so that what= we
> list there and what is in the announcement are consistent.

+1.

> On the actual list, there will be lots of opinions to be had, but I= 9;ll
> just offer one:=C2=A0 I don't think the MERGE RETURNING clause des= erves twice
> as much space as incremental backup.

I agree with that, although obviously I'm biased.

I also feel like this whole thing could just be shorter. If it were
half as long and mentioned fewer things and those more briefly, would
we be worse off? I think we might be better off, because it just feels
wordy to me right now. For example:

A foundational feature of PostgreSQL is
[vacuum](https://www.postgresql.org/docs/17= /routine-vacuuming.html),
which is used to reclaim storage from data that was marked as removed.
Reducing resources required for vacuuming directly helps other areas
of PostgreSQL, particularly on very busy systems. PostgreSQL 17
introduces a new internal memory structure for vacuum that's shown up to a 20x reduction in memory and improvements in overall vacuuming
speed. This release also removes the=C2=A0 `1GB` limit on the memory it can=
use (controlled by
[`maintenance_work_mem`](https://www.postgresql.org/docs/17/runtime-config-resource.ht= ml#GUC-MAINTENANCE-WORK-MEM)),
letting users apply more resources to vacuuming, which is beneficial
for systems with lots of changes.

It seems to me that the first two sentences could just be completely
nuked, and everything from "letting users" to the end could also = be
nuked. At least to me, all of that stuff reads as unnecessarily
filler. I'm not at all sure that removing the 1GB limit on
maintenance_work_mem is important enough that it needs to be in the
release announcement -- I agree it's a good improvement, but to have it be one of the first things in the press release seems like an odd
choice from my perspective. Nobody's going to look back on this
release years from now and say "oh, that was the release where could finally set maintenance_work_mem=3D4GB, that was so much better". If they think about VACUUM, they'll think about the 20x memory reduction stuff which made the ability to configure values larger than 1GB
irrelevant in the first place. So I'd probably delete the part about lifting the 1GB cap entirely. But even if you don't do that, the
paragraph could be half as long without losing anything, from my
perspective.

--
Robert Haas
EDB: http://www.enterprisedb.com


--00000000000077cecd062163b02a--