I think that the removal of the "adminpack" extension should
be listed in the section "migration to v17" as an incompatibility.
I have seen one complaint that pg_upgrade fails if the extension
is installed, but a dump/restore would also throw an error.
Yours,
Laurenz Albe
From bab39739eb13f57572b
On Sat, 28 Sep 2024 21:19:11 -0400
Bruce Momjian wrote:
> On Thu, Sep 26, 2024 at 02:19:21PM +0900, Yugo Nagata wrote:
> > On Thu, 9 May 2024 00:03:50 -0400
> > Bruce Momjian wrote:
> >
> > > I have committed the first draft of the PG 17 release notes; you can
> > > see the results here:
> >
On Sun, Sep 29, 2024 at 6:50 AM Bruce Momjian wrote:
>
> On Thu, Sep 26, 2024 at 03:08:52PM +0530, Amit Kapila wrote:
> > On Sat, Sep 21, 2024 at 1:50 AM Bruce Momjian wrote:
> > >
> > > On Fri, Sep 20, 2024 at 04:05:11PM -0400, Tom Lane wrote:
> > > > Bruce Momjian writes:
> > > > > Patch appli
On Thu, Sep 26, 2024 at 03:08:52PM +0530, Amit Kapila wrote:
> On Sat, Sep 21, 2024 at 1:50 AM Bruce Momjian wrote:
> >
> > On Fri, Sep 20, 2024 at 04:05:11PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Patch applied to PG 17.
> > >
> > > I don't see a push?
> >
> > Push was delaye
On Thu, Sep 26, 2024 at 02:19:21PM +0900, Yugo Nagata wrote:
> On Thu, 9 May 2024 00:03:50 -0400
> Bruce Momjian wrote:
>
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
>
> I propose to improve the following description in "Migration to Versio
On Sat, Sep 21, 2024 at 1:50 AM Bruce Momjian wrote:
>
> On Fri, Sep 20, 2024 at 04:05:11PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Patch applied to PG 17.
> >
> > I don't see a push?
>
> Push was delayed because my test script found some uncommitted files due
> to earlier testing.
On Thu, 9 May 2024 00:03:50 -0400
Bruce Momjian wrote:
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
I propose to improve the following description in "Migration to Version 17"
section by adding CREATE INDEX and CREATE MATERIALIZED VIEW into the
Laurenz Albe writes:
> [ assorted corrections ]
I fixed a couple of these before seeing your message.
regards, tom lane
On Fri, Sep 20, 2024 at 04:05:11PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Patch applied to PG 17.
>
> I don't see a push?
Push was delayed because my test script found some uncommitted files due
to earlier testing. Should be fine now.
--
Bruce Momjian https://momjian.us
On Fri, 2024-09-20 at 13:47 -0400, Jonathan S. Katz wrote:
> Please see attached.
> +
> +
> + Various query performance improvements, including to sequential reads
> + using streaming I/O, write throughput under high concurrency, and
> + searches over multiple values in a b
Bruce Momjian writes:
> Patch applied to PG 17.
I don't see a push?
regards, tom lane
On Fri, Sep 20, 2024 at 01:47:43PM -0400, Jonathan Katz wrote:
> On 9/20/24 12:55 PM, Laurenz Albe wrote:
> > On Fri, 2024-09-20 at 10:02 -0400, Jonathan S. Katz wrote:
> > > Attached is a proposal for the major features section. This borrows from
> > > the release announcement draft[1] and lists o
On 9/20/24 12:55 PM, Laurenz Albe wrote:
On Fri, 2024-09-20 at 10:02 -0400, Jonathan S. Katz wrote:
Attached is a proposal for the major features section. This borrows from
the release announcement draft[1] and lists out features and themes that
have broad user impact. This was a bit challenging
On Fri, 2024-09-20 at 10:02 -0400, Jonathan S. Katz wrote:
> Attached is a proposal for the major features section. This borrows from
> the release announcement draft[1] and lists out features and themes that
> have broad user impact. This was a bit challenging for this release,
> because there
On 5/9/24 12:03 AM, Bruce Momjian wrote:
I have committed the first draft of the PG 17 release notes; you can
see the results here:
release-17: 188
I welcome feedback. For some reason it was an easier job than usual.
Attached is a proposal for the major features section. This borro
On Thu, Sep 19, 2024 at 1:04 PM Bruce Momjian wrote:
> I mentioned the SPI macros because that could lead to breakage, and
> there might be applications, as well as extensions, that use it.
Sure, this is all a judgement call. I don't think it's particularly
likely that many people are relying on
On Thu, Sep 19, 2024 at 12:23:21PM -0400, Robert Haas wrote:
> On Wed, Sep 18, 2024 at 9:09 PM Nathan Bossart
> wrote:
> > On Wed, Sep 18, 2024 at 05:33:18PM -0400, Bruce Momjian wrote:
> > > On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
> > >> Another new API that is useful
On Wed, Sep 18, 2024 at 9:09 PM Nathan Bossart wrote:
> On Wed, Sep 18, 2024 at 05:33:18PM -0400, Bruce Momjian wrote:
> > On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
> >> Another new API that is useful for extension authors is the following
> >> one (I'm obviously biased si
On Wed, Sep 18, 2024 at 05:33:18PM -0400, Bruce Momjian wrote:
> On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
>> Another new API that is useful for extension authors is the following
>> one (I'm obviously biased since I'm the author, and I don't know if
>> there's still time):
On Tue, Sep 17, 2024 at 10:01:28AM +0200, Jelte Fennema-Nio wrote:
> On Wed, 11 Sept 2024 at 16:10, Bruce Momjian wrote:
> > You are right that I do mention changes specifically designed for the
> > use of extensions, but there is no mention in the commit message of its
> > use for extensions. In
On 2024-Sep-11, Bruce Momjian wrote:
> An interesting idea would be to report all function signature changes
> in each major release in some way.
Hmm, extension authors are going to realize this as soon as they try to
compile, so it doesn't seem necessary. Having useful APIs _added_ is a
differe
On Wed, 11 Sept 2024 at 16:10, Bruce Momjian wrote:
> You are right that I do mention changes specifically designed for the
> use of extensions, but there is no mention in the commit message of its
> use for extensions. In fact, I thought this was too low-level to be of
> use for extensions. How
On Wed, Sep 11, 2024 at 07:50:40PM +0200, Álvaro Herrera wrote:
> There's also a bunch of items on EXPLAIN, which could perhaps be grouped
> in a single item with sub-paras for each individual change; I'd also
> move it to the bottom of E.1.3.2.
Oh, I hadn't noticed I have five EXPLAIN items --- t
On Wed, Sep 11, 2024 at 07:50:40PM +0200, Álvaro Herrera wrote:
> Hello,
>
> I noticed that these two items in the current notes are separate:
>
>
>
>
>
> Allow specification of partitioned table
> access methods (Justin Pryzby, Soumyadeep Chakraborty,
> Michael P
On Fri, Sep 13, 2024 at 04:17:31PM -0400, Bruce Momjian wrote:
> Attached patch applied, with commit URL link.
Looks good, thanks.
--
nathan
On Wed, Sep 11, 2024 at 09:36:35AM -0500, Nathan Bossart wrote:
> On Wed, Sep 11, 2024 at 10:12:58AM -0400, Bruce Momjian wrote:
> > On Tue, Sep 10, 2024 at 09:52:42AM -0700, Masahiko Sawada wrote:
> >> On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio
> >> wrote:
> >> > For 1, I think adding the
Hello,
I noticed that these two items in the current notes are separate:
Allow specification of partitioned table
access methods (Justin Pryzby, Soumyadeep Chakraborty,
Michael Paquier)
Add DEFAULT setting for ALTER TABLE
.
On Wed, Sep 11, 2024 at 10:12:58AM -0400, Bruce Momjian wrote:
> On Tue, Sep 10, 2024 at 09:52:42AM -0700, Masahiko Sawada wrote:
>> On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio wrote:
>> > For 1, I think adding them to the release notes makes total sense,
>> > especially if the new APIs are
On Tue, Sep 10, 2024 at 09:52:42AM -0700, Masahiko Sawada wrote:
> On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio wrote:
> >
> > On Tue, 10 Sept 2024 at 04:47, Bruce Momjian wrote:
> > > Yes. There are so many changes at the source code level it is unwise to
> > > try and get them into the ma
On Tue, Sep 10, 2024 at 08:28:42AM +0200, Jelte Fennema-Nio wrote:
> I think as an extension author there are usually three types of
> changes that are relevant:
> 1. New APIs/hooks that are meant for extension authors
> 2. Stuff that causes my existing code to not compile anymore
> 3. Stuff that c
On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio wrote:
>
> On Tue, 10 Sept 2024 at 04:47, Bruce Momjian wrote:
> > Yes. There are so many changes at the source code level it is unwise to
> > try and get them into the main release notes. If someone wants to
> > create an addendum, like was sug
On 2024-Sep-10, Jelte Fennema-Nio wrote:
> I think as an extension author there are usually three types of
> changes that are relevant:
>
> 1. New APIs/hooks that are meant for extension authors
> For 1, I think adding them to the release notes makes total sense,
> especially if the new APIs are
On Thu, Sep 05, 2024 at 09:51:25PM -0400, Bruce Momjian wrote:
> On Tue, Sep 3, 2024 at 10:44:01AM -0500, Nathan Bossart wrote:
> > While freely acknowledging that I am biased because I wrote it, I am a bit
> > surprised to see the DSM registry left out of the release notes (commit
> > 8b2bcf3, do
On Tue, 10 Sept 2024 at 04:47, Bruce Momjian wrote:
> Yes. There are so many changes at the source code level it is unwise to
> try and get them into the main release notes. If someone wants to
> create an addendum, like was suggested for pure performance
> improvements, that would make sense.
On Sat, Sep 7, 2024 at 11:55:09AM +0200, Álvaro Herrera wrote:
> On 2024-Sep-05, Bruce Momjian wrote:
>
> > That seems more infrastructure/extension author stuff which isn't
> > normally mentioned in the release notes. I think such people really
> > need to look at all the commit messages.
>
>
On 2024-Sep-05, Bruce Momjian wrote:
> That seems more infrastructure/extension author stuff which isn't
> normally mentioned in the release notes. I think such people really
> need to look at all the commit messages.
Are you saying all extension authors should be reading the complete git
log fo
On Tue, Sep 3, 2024 at 10:44:01AM -0500, Nathan Bossart wrote:
> While freely acknowledging that I am biased because I wrote it, I am a bit
> surprised to see the DSM registry left out of the release notes (commit
> 8b2bcf3, docs are here [0]). This feature is intended to allow modules to
> alloc
On Wed, Sep 4, 2024 at 07:18:52PM +0800, jian he wrote:
> hi.
>
> Allow partitions to be merged using ALTER TABLE ... MERGE PARTITIONS
> (Dmitry Koval)
> Allow partitions to be split using ALTER TABLE ... SPLIT PARTITION
> (Dmitry Koval)
>
> also these two items got reverted? see
> https://git.p
hi.
Allow partitions to be merged using ALTER TABLE ... MERGE PARTITIONS
(Dmitry Koval)
Allow partitions to be split using ALTER TABLE ... SPLIT PARTITION
(Dmitry Koval)
also these two items got reverted? see
https://git.postgresql.org/cgit/postgresql.git/commit/?id=3890d90c1508125729ed20038d9051
While freely acknowledging that I am biased because I wrote it, I am a bit
surprised to see the DSM registry left out of the release notes (commit
8b2bcf3, docs are here [0]). This feature is intended to allow modules to
allocate shared memory after startup, i.e., without requiring the module to
b
On Thu, Aug 8, 2024 at 08:55:53AM -0500, Justin Pryzby wrote:
> > Add server variable huge_page_size to report the use of huge pages by
>
> The new variable is huge_page_status; h_p_size is several years old.
Fixed. I created this mistake when I was adding links to the SGML file.
> BTW, I was
On Fri, Jul 26, 2024 at 01:22:24PM +0900, Yugo Nagata wrote:
> I found the following in the release notes:
>
> Change file boundary handling of two WAL file name functions
> (Kyotaro Horiguchi, Andres Freund, Bruce Momjian)
>
> The functions pg_walfile_name() and pg_walfile_name_offset() used
On Wed, Jul 17, 2024 at 03:32:45PM +0900, Kisoon Kwon wrote:
> Hi,
>
> In the PG17 release notes, I noticed it is mentioned as
> "pg_attribute.stxstattarget" which seems incorrect.
> In my opinion, it should be "pg_statistic_ext.stxstattarget" because the
> "stxstattarget" column is part of the "p
> Add server variable huge_page_size to report the use of huge pages by
The new variable is huge_page_status; h_p_size is several years old.
BTW, I was surprised that these were included:
+2024-02-28 [363eb0599] Convert README to Markdown.
+2024-01-25 [7014c9a4b] Doc: improve documentation for j
Hi,
On Thu, 9 May 2024 00:03:50 -0400
Bruce Momjian wrote:
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql_docs/release-17.html
>
> It will be improved until the final release. The item count is 188,
> which is
Hi,
In the PG17 release notes, I noticed it is mentioned as
"pg_attribute.stxstattarget" which seems incorrect.
In my opinion, it should be "pg_statistic_ext.stxstattarget" because the
"stxstattarget" column is part of the "pg_statistic_ext" catalog.
Regards,
Kisoon Kwon
Bitnine Global (www.bitni
On Fri, Jul 5, 2024 at 07:51:38PM +0200, Matthias van de Meent wrote:
> Hi,
>
> I noticed that PG17's release note for commit cafe10565 is "Allow psql
> connections to be canceled with control-C (Tristan Partin)", but this
> summary seems wrong to me.
>
> We already had ^C connection (query) can
Hi,
I noticed that PG17's release note for commit cafe10565 is "Allow psql
connections to be canceled with control-C (Tristan Partin)", but this
summary seems wrong to me.
We already had ^C connection (query) cancellation for quite some time
before this patch. What's new with that patch, is that
On Wed, Jun 5, 2024 at 11:46:17PM +0100, Dean Rasheed wrote:
> On Thu, 9 May 2024 at 05:03, Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
>
> I noticed a c
On Thu, 9 May 2024 at 05:03, Bruce Momjian wrote:
>
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql_docs/release-17.html
I noticed a couple more things. This item:
Add functions to convert integers to hex and
On Tue, May 28, 2024 at 02:44:28PM +1200, David Rowley wrote:
> On Sun, 26 May 2024 at 15:57, Bruce Momjian wrote:
> > Agreed. I changed it to:
> >
> > Allow btree indexes to more efficiently find a set of values, such
> > as
> > those supplied by IN subqueries
> >
> > Is that go
On Sun, 26 May 2024 at 15:57, Bruce Momjian wrote:
> Agreed. I changed it to:
>
> Allow btree indexes to more efficiently find a set of values, such as
> those supplied by IN subqueries
>
> Is that good?
I think this needs further adjustment. An "IN subquery" is an IN
clause whi
On Sun, May 26, 2024 at 10:10:00AM +0200, Álvaro Herrera wrote:
> On 2024-May-25, Bruce Momjian wrote:
>
> > On Thu, May 23, 2024 at 01:22:51PM +0200, Álvaro Herrera wrote:
>
> > > Can we make them a single item? Maybe something like
> > >
> > > : Improve reset routines for shared statistics (A
On 2024-May-25, Bruce Momjian wrote:
> On Thu, May 23, 2024 at 01:22:51PM +0200, Álvaro Herrera wrote:
> > Can we make them a single item? Maybe something like
> >
> > : Improve reset routines for shared statistics (Atsushi Torikoshi, Bharath
> > Rupireddy)
> > :
> > : Resetting all shared sta
On Thu, May 23, 2024 at 08:19:15PM -0400, Peter Geoghegan wrote:
> On Wed, May 22, 2024 at 6:50 PM Bruce Momjian wrote:
> > Agreed, patch applied, thanks.
>
> The item for my commit 5bf748b8 currently reads:
>
> "Allow btree indexes to more efficiently find array matches"
>
> I think that this
On Thu, May 23, 2024 at 04:54:28PM -0300, Marcos Pegoraro wrote:
> • Rename SLRU columns in system view pg_stat_slru (Alvaro Herrera)
>
> The column names accepted by pg_stat_slru_rest() are also changed.
>
> Is pg_stat_slru_rest() correct ?
Oops, typo, fixed, thanks.
--
Bruce Momjian
On Thu, May 23, 2024 at 01:22:51PM +0200, Álvaro Herrera wrote:
> Hello,
>
> Regarding this item
>
> : Allow the SLRU cache sizes to be configured (Andrey Borodin, Dilip Kumar)
> :
> : The new server variables are commit_timestamp_buffers,
> : multixact_member_buffers, multixact_offset_buffers,
On Fri, May 24, 2024 at 11:23:29AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-22 18:33:03 -0400, Bruce Momjian wrote:
> > On Tue, May 21, 2024 at 09:40:28AM -0700, Andres Freund wrote:
> > > On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> > > I agree keeping things reasonably short is i
On Fri, May 24, 2024 at 10:50:28AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-23 23:27:04 -0400, Bruce Momjian wrote:
> > On Thu, May 23, 2024 at 11:11:10PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > I am not sure Bruce that you realize that your disregard for
> > > performanc
On Fri, May 24, 2024 at 1:50 PM Andres Freund wrote:
> Bruce, just about everyone seems to disagree with your current approach. And
> not just this year, this has been a discussion in most if not all release note
> threads of the last few years.
+1.
> People, including me, *have* addressed your
Hi,
On 2024-05-22 18:33:03 -0400, Bruce Momjian wrote:
> On Tue, May 21, 2024 at 09:40:28AM -0700, Andres Freund wrote:
> > On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> > I agree keeping things reasonably short is important. But I don't think
> > you're
> > evenly applying it as a goal.
>
Hi,
On 2024-05-23 23:27:04 -0400, Bruce Momjian wrote:
> On Thu, May 23, 2024 at 11:11:10PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > I am not sure Bruce that you realize that your disregard for
> > performance improvements is shared by nobody. Arguably,
> > performance is 90% of what
On Thu, May 23, 2024 at 11:04 PM Bruce Momjian wrote:
> For a case where O(N^2) become O(N), we might not even know the
> performance change since it is a micro-optimization. That is why I
> suggested we call it "Internal Performance".
I don't get this at all. If we can't tell the difference bet
On Thu, May 23, 2024 at 11:11:10PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, May 23, 2024 at 02:27:07PM +1200, David Rowley wrote:
> >> I also don't agree these should be left to "Source code" section. I
> >> feel that section is best suited for extension authors who might care
>
Bruce Momjian writes:
> On Thu, May 23, 2024 at 02:27:07PM +1200, David Rowley wrote:
>> I also don't agree these should be left to "Source code" section. I
>> feel that section is best suited for extension authors who might care
>> about some internal API change. I'm talking of stuff that makes
On Thu, May 23, 2024 at 02:27:07PM +1200, David Rowley wrote:
> On Thu, 23 May 2024 at 14:01, Bruce Momjian wrote:
> >
> > On Thu, May 23, 2024 at 01:34:10PM +1200, David Rowley wrote:
> > > What is the best way to communicate this stuff so it's easily
> > > identifiable when you parse the commit
On Wed, May 22, 2024 at 6:50 PM Bruce Momjian wrote:
> Agreed, patch applied, thanks.
The item for my commit 5bf748b8 currently reads:
"Allow btree indexes to more efficiently find array matches"
I think that this isn't likely to mean much to most users. It seems
like it'd be a lot clearer if t
-
Rename SLRU columns in system view pg_stat_slru (Alvaro Herrera)
The column names accepted by pg_stat_slru_rest() are also changed.
Is pg_stat_slru_rest() correct ?
On Wed, 2024-05-22 at 18:39 -0400, Bruce Momjian wrote:
> On Mon, May 20, 2024 at 11:48:09AM -0700, Jeff Davis wrote:
> > On Sat, 2024-05-18 at 17:51 -0400, Bruce Momjian wrote:
> > > Okay, I went with the attached applied patch. Adjustments?
> >
> > I think it should have more emphasis on the ac
Hello,
Regarding this item
: Allow the SLRU cache sizes to be configured (Andrey Borodin, Dilip Kumar)
:
: The new server variables are commit_timestamp_buffers,
: multixact_member_buffers, multixact_offset_buffers, notify_buffers,
: serializable_buffers, subtransaction_buffers, and transaction_
On Thu, 23 May 2024 at 14:01, Bruce Momjian wrote:
>
> On Thu, May 23, 2024 at 01:34:10PM +1200, David Rowley wrote:
> > What is the best way to communicate this stuff so it's easily
> > identifiable when you parse the commit messages?
>
> This is why I think we need an "Internal Performance" sect
On Thu, May 23, 2024 at 01:34:10PM +1200, David Rowley wrote:
> On Thu, 23 May 2024 at 10:04, Bruce Momjian wrote:
> > You might have seen in this thread, I do record commits that speed up
> > workloads that are user-visible, or specifically make new workloads
> > possible. I assume that covers t
On Thu, 23 May 2024 at 10:04, Bruce Momjian wrote:
> You might have seen in this thread, I do record commits that speed up
> workloads that are user-visible, or specifically make new workloads
> possible. I assume that covers the items above, though I have to
> determine this from the commit mess
On Wed, May 22, 2024 at 09:25:41PM +0900, torikoshia wrote:
> Thanks for working on this as always.
>
>
> Allow pg_stat_reset_shared("slru") to clear SLRU statistics (Atsushi
> Torikoshi)
>
>
> Considering someone may copy and paste this, 'slru' is better than "slru",
> isn't it?
> I also found
On Wed, May 22, 2024 at 11:29:06AM +0900, Masahiko Sawada wrote:
> I found a typo:
>
> s/pg_statstatement/pg_stat_statement/
>
> I've attached a patch to fix it.
Agreed, applied, thanks.
--
Bruce Momjian https://momjian.us
EDB https://enterpris
On Tue, May 21, 2024 at 11:20:02AM +0900, Amit Langote wrote:
> Thanks Bruce for working on this as always.
>
> Failed to notice when I read the notes before:
>
>
>
> Add SQL/JSON constructor functions JSON(), JSON_SCALAR(), and
> JSON_SERIALIZE() (Amit Langote)
>
>
>
> Should be:
>
>
>
>
On Mon, May 20, 2024 at 11:48:09AM -0700, Jeff Davis wrote:
> On Sat, 2024-05-18 at 17:51 -0400, Bruce Momjian wrote:
> > Okay, I went with the attached applied patch. Adjustments?
>
> I think it should have more emphasis on the actual new feature: a
> platform-independent builtin collation provi
On Tue, May 21, 2024 at 09:40:28AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> > Please see the email I just posted. There are three goals we have to
> > adjust for:
> >
> > 1. short release notes so they are readable
> > 2. giving people credit f
On Tue, May 21, 2024 at 02:26:15PM -0400, Melanie Plageman wrote:
> In Postgres development, we break larger projects into smaller ones
> and then those smaller projects into multiple individual commits. Each
> commit needs to stand alone and each subproject needs to have a
> defensible benefit. On
On Tue, May 21, 2024 at 01:50:58PM -0400, Robert Haas wrote:
> On Tue, May 21, 2024 at 12:27 PM Andres Freund wrote:
> > To me that's the "General Performance" section. If somebody reading the
> > release notes doesn't care about performance, they can just skip that
> > section
> > ([1]). I don'
On Tue, May 21, 2024 at 09:51:09AM -0700, Andres Freund wrote:
> Hi,
>
> On 2024-05-21 09:27:20 -0700, Andres Freund wrote:
> > Also, the release notes are also not just important to users. I often go
> > back
> > and look in the release notes to see when some some important change was
> > made,
On Tue, May 21, 2024 at 09:27:20AM -0700, Andres Freund wrote:
> On 2024-05-18 10:59:47 -0400, Bruce Momjian wrote:
> > I agree the impact of performance improvements are often greater than
> > the average release note item. However, if people expect Postgres to be
> > faster, is it important for
On Mon, May 20, 2024 at 02:47:28PM -0400, Melanie Plageman wrote:
> On Mon, May 20, 2024 at 9:37 AM Bruce Momjian wrote:
> >
> > On Mon, May 20, 2024 at 01:23:02PM +0700, John Naylor wrote:
> > > Hi Bruce, thanks for doing this again!
> > >
> > > I'm a bit late to this discussion -- there's been a
On 2024-May-21, Andres Freund wrote:
> Which reminds me: Eventually I'd like to add links to the most important
> commits related to release note entries. We already do much of the work of
> building that list of commits for each entry. That'd allow a reader to find
> more details if interested.
On 2024-05-09 13:03, Bruce Momjian wrote:
I have committed the first draft of the PG 17 release notes; you can
see the results here:
https://momjian.us/pgsql_docs/release-17.html
It will be improved until the final release. The item count is 188,
which is similar to recent releases:
Hi,
On Thu, May 9, 2024 at 1:03 PM Bruce Momjian wrote:
>
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql_docs/release-17.html
>
> It will be improved until the final release. The item count is 188,
> which is s
On Tue, May 21, 2024 at 2:26 PM Melanie Plageman
wrote:
> For the vacuum WAL volume reduction, there were a bunch of smaller
> projects throughout the last development year that I worked on that
> were committed by different people and with different individual
> benefits. Some changes caused vacu
On Tue, May 21, 2024 at 1:51 PM Robert Haas wrote:
>
> On Tue, May 21, 2024 at 12:27 PM Andres Freund wrote:
> > To me that's the "General Performance" section. If somebody reading the
> > release notes doesn't care about performance, they can just skip that
> > section
> > ([1]). I don't see w
On Tue, May 21, 2024 at 12:27 PM Andres Freund wrote:
> To me that's the "General Performance" section. If somebody reading the
> release notes doesn't care about performance, they can just skip that section
> ([1]). I don't see why we wouldn't want to include the same level of detail
> as for ot
On Tue, May 21, 2024 at 12:27 PM Andres Freund wrote:
> > I agree the impact of performance improvements are often greater than
> > the average release note item. However, if people expect Postgres to be
> > faster, is it important for them to know _why_ it is faster?
>
> Yes, it very often is.
Hi,
On 2024-05-21 09:27:20 -0700, Andres Freund wrote:
> Also, the release notes are also not just important to users. I often go back
> and look in the release notes to see when some some important change was made,
> because sometimes it's harder to find it in the git log, due to sheer
> volume.
Hi,
On 2024-05-18 11:13:54 -0400, Bruce Momjian wrote:
> Please see the email I just posted. There are three goals we have to
> adjust for:
>
> 1. short release notes so they are readable
> 2. giving people credit for performance improvements
> 3. showing people Postgres cares about performan
Hi,
On 2024-05-18 10:59:47 -0400, Bruce Momjian wrote:
> On Wed, May 15, 2024 at 08:48:02PM -0700, Andres Freund wrote:
> > +many.
> >
> > We're having this debate every release. I think the ongoing reticence to
> > note
> > performance improvements in the release notes is hurting Postgres.
> >
>
On Thu, May 9, 2024 at 1:04 PM Bruce Momjian wrote:
> I have committed the first draft of the PG 17 release notes; you can
> see the results here:
>
> https://momjian.us/pgsql_docs/release-17.html
>
> It will be improved until the final release. The item count is 188,
> which is similar
On Sat, 2024-05-18 at 17:51 -0400, Bruce Momjian wrote:
> Okay, I went with the attached applied patch. Adjustments?
I think it should have more emphasis on the actual new feature: a
platform-independent builtin collation provider and the C.UTF-8 locale.
The user can look at the documentation fo
On Mon, May 20, 2024 at 9:37 AM Bruce Momjian wrote:
>
> On Mon, May 20, 2024 at 01:23:02PM +0700, John Naylor wrote:
> > Hi Bruce, thanks for doing this again!
> >
> > I'm a bit late to this discussion -- there's been a bit of churn in
> > the vacuum items, and some streams got crossed along the
On Mon, May 20, 2024 at 02:35:37PM -0400, Melanie Plageman wrote:
> On Sat, May 18, 2024 at 11:13 AM Bruce Momjian wrote:
> > Please see the email I just posted. There are three goals we have to
> > adjust for:
> >
> > 1. short release notes so they are readable
> > 2. giving people credit for
On Sat, May 18, 2024 at 11:13 AM Bruce Momjian wrote:
>
> On Thu, May 16, 2024 at 09:09:11AM -0400, Melanie Plageman wrote:
> > On Wed, May 15, 2024 at 11:48 PM Andres Freund wrote:
> > >
> > > On 2024-05-15 10:38:20 +0200, Alvaro Herrera wrote:
> > > > I disagree with this. IMO the impact of th
On Mon, May 20, 2024 at 01:23:02PM +0700, John Naylor wrote:
> Hi Bruce, thanks for doing this again!
>
> I'm a bit late to this discussion -- there's been a bit of churn in
> the vacuum items, and some streams got crossed along the way. I've
> attached an attempt to rectify this.
Agreed, patch a
Hi Bruce, thanks for doing this again!
I'm a bit late to this discussion -- there's been a bit of churn in
the vacuum items, and some streams got crossed along the way. I've
attached an attempt to rectify this.
diff --git a/doc/src/sgml/release-17.sgml b/doc/src/sgml/release-17.sgml
index 0e7ff51f
1 - 100 of 202 matches
Mail list logo
