PostgreSQL 12: Feature Highlights

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
63 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Amit Langote-2
On 2019/05/14 11:59, Bruce Momjian wrote:

> On Mon, May 13, 2019 at 10:50:59PM +1200, David Rowley wrote:
>> On Mon, 13 May 2019 at 18:37, Amit Langote
>> <[hidden email]> wrote:
>>> It's true that optimizer and executor can now handle larger number of
>>> partitions efficiently, but the improvements in this release will only be
>>> meaningful to workloads where partition pruning is crucial, so I don't see
>>> why mentioning "pruning" is so misleading.  Perhaps, it would be slightly
>>> misleading to not mention it, because readers might think that queries
>>> like this one:
>>>
>>>   select count(*) from partitioned_table;
>>>
>>> are now faster in v12, whereas AFAIK, they perform perform more or less
>>> the same as in v11.
>>
>> This is true, but whether partitions are pruned or not is only
>> relevant to one of the many items the headline feature is talking
>> about. I'm not sure how you'd briefly enough mention that fact without
>> going into detail about which features are which and which are
>> affected by partition pruning.
>>
>> I think these are the sorts of details that can be mentioned away from
>> the headline features, which is why I think lumping these all in one
>> in the main release notes is a bad idea as it's pretty hard to do that
>> when they're all lumped in as one item.
>
> I think the point is that partition pruning and tuple _routing_ to the
> right partition is also improved.  I updated the release note items to
> say:
>
> Tables with thousands of child partitions can now be processed
> efficiently.

Considering the quoted discussion here, maybe it's a good idea to note
that only the operations that need to touch a small number of partitions
are now processed efficiently, which covers both SELECT/UPDATE/DELETE that
benefit from improved pruning efficiency and INSERT that benefit from
improved tuple routing efficiency.  So, maybe:

        Tables with thousands of child partitions can now be processed
        efficiently by operations that only need to touch a small number
        of partitions.

That is, as I mentioned above, as opposed to queries that need to process
all partitions (such as, select count(*) from partitioned_table), which
don't perform any faster in v12 than in v11.  The percentage of users who
run such workloads on PostgreSQL may be much smaller today, but perhaps
it's not a good idea to mislead them into thinking that *everything* with
partitioned tables is now faster even with thousands of partitions.

Thanks,
Amit



Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Bruce Momjian
On Tue, May 14, 2019 at 06:25:43PM +0900, Amit Langote wrote:

> Considering the quoted discussion here, maybe it's a good idea to note
> that only the operations that need to touch a small number of partitions
> are now processed efficiently, which covers both SELECT/UPDATE/DELETE that
> benefit from improved pruning efficiency and INSERT that benefit from
> improved tuple routing efficiency.  So, maybe:
>
> Tables with thousands of child partitions can now be processed
> efficiently by operations that only need to touch a small number
>         of partitions.
>
> That is, as I mentioned above, as opposed to queries that need to process
> all partitions (such as, select count(*) from partitioned_table), which
> don't perform any faster in v12 than in v11.  The percentage of users who
> run such workloads on PostgreSQL may be much smaller today, but perhaps
> it's not a good idea to mislead them into thinking that *everything* with
> partitioned tables is now faster even with thousands of partitions.

Agreed, I changed it to your wording.

--
  Bruce Momjian  <[hidden email]>        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 +


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Amit Langote-2
On 2019/05/14 22:19, Bruce Momjian wrote:

> On Tue, May 14, 2019 at 06:25:43PM +0900, Amit Langote wrote:
>> Considering the quoted discussion here, maybe it's a good idea to note
>> that only the operations that need to touch a small number of partitions
>> are now processed efficiently, which covers both SELECT/UPDATE/DELETE that
>> benefit from improved pruning efficiency and INSERT that benefit from
>> improved tuple routing efficiency.  So, maybe:
>>
>> Tables with thousands of child partitions can now be processed
>> efficiently by operations that only need to touch a small number
>>         of partitions.
>>
>> That is, as I mentioned above, as opposed to queries that need to process
>> all partitions (such as, select count(*) from partitioned_table), which
>> don't perform any faster in v12 than in v11.  The percentage of users who
>> run such workloads on PostgreSQL may be much smaller today, but perhaps
>> it's not a good idea to mislead them into thinking that *everything* with
>> partitioned tables is now faster even with thousands of partitions.
>
> Agreed, I changed it to your wording.

Thank you.

Regards,
Amit




Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Jonathan S. Katz-3
In reply to this post by Jonathan S. Katz-3
Hi,

On 5/12/19 11:28 AM, Jonathan S. Katz wrote:
> Hi,
>
> Now that a draft of the release notes are available[1] this seems like a
> good time to begin determining what features we want to highlight prior
> to the Beta 1 announcement.

Thank you everyone for your feedback. Below is v2 of the list for the
Beta 1 announcement. A few things to note:

- Based on feedback I made several INSERT/UPDATE/DELETE operations on
the list ;)

- I know it's listing out a lot of features, but this is the Beta 1
release, which, among several goals, is to make people aware of as many
impactful features as possible for purposes of awareness and getting
people to help test.

- The press release will be better worded - this is just a list :)

Without further ado:

# Feature Highlights

1. Indexing

- Improvements overall performance to standard (B-tree) indexes with
writes as well as with bloat
- REINDEX CONCURRENTLY
- GiST indexes now support covering indexes (INCLUDE clause)
- SP-GiST indexes now support K-NN queries
- WAL overhead reduced on GiST, GIN, & SP-GiST index creation

2. Partitioning Improvements

- Improved partition pruning, which improves performance on queries over
tables with thousands of partitions that only need to use a few partitions
- Improvements to COPY performance and ATTACH PARTITION
- Allow foreign keys to reference partitioned tables

3. WITH queries (CTEs) can now be inlined, subject to certain restrictions

4. Support for JSON path queries per the SQL/JSON specification in the
SQL:2016 standard. A subset of these expressions can be accelerated with
on-disk indexes.

5. Support for case-insensitive and accent-insensitive collations

6. CREATE STATISTICS now supports most-common value statistics, which
leads to improved query plans for distributions that are non-uniform

7. Introduction of generated columns that compute and store an
expression as a value on the table

8. Introduction of CREATE ACCESS METHOD that permits the addition of new
table storage types

9. Enable / disable page checksums for an offline cluster

10. Authentication

- GSSAPI client/server encryption support
- LDAP server discovery

# Changes That Can Affect Existing Operating Environments

1. recovery.conf merged into postgresql.conf;
recovery.signal/standby.signal being used for switching into non-primary
mode

2. JIT enabled by default

Thanks,

Jonathan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Amit Langote-2
Hi Jonathan,

Thanks for the updated draft.

On 2019/05/15 11:03, Jonathan S. Katz wrote:

> Without further ado:
>
> # Feature Highlights
>
> 1. Indexing
>
> - Improvements overall performance to standard (B-tree) indexes with
> writes as well as with bloat
> - REINDEX CONCURRENTLY
> - GiST indexes now support covering indexes (INCLUDE clause)
> - SP-GiST indexes now support K-NN queries
> - WAL overhead reduced on GiST, GIN, & SP-GiST index creation
>
> 2. Partitioning Improvements
>
> - Improved partition pruning, which improves performance on queries over
> tables with thousands of partitions that only need to use a few partitions
> - Improvements to COPY performance and ATTACH PARTITION
> - Allow foreign keys to reference partitioned tables

About the 1st item in "Partitioning Improvements", it's not just partition
pruning that's gotten better.  How about writing as:

 - Improved performance of processing tables with thousands of partitions
   for operations that only need to touch a small number of partitions

Per discussion upthread, that covers improvements to both partition
pruning and tuple routing.

Also, could the title "2. Partitioning Improvements" be trimmed down to
"2. Partitioning", to look like "1. Indexing" for consistency?

Thanks,
Amit



Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

David Rowley-3
On Wed, 15 May 2019 at 14:31, Amit Langote
<[hidden email]> wrote:

>
> On 2019/05/15 11:03, Jonathan S. Katz wrote:
> > 2. Partitioning Improvements
> >
> > - Improved partition pruning, which improves performance on queries over
> > tables with thousands of partitions that only need to use a few partitions
> > - Improvements to COPY performance and ATTACH PARTITION
> > - Allow foreign keys to reference partitioned tables
>
> About the 1st item in "Partitioning Improvements", it's not just partition
> pruning that's gotten better.  How about writing as:
>
>  - Improved performance of processing tables with thousands of partitions
>    for operations that only need to touch a small number of partitions
>
> Per discussion upthread, that covers improvements to both partition
> pruning and tuple routing.

+1. Amit's words look fine to me.   I think if we're including this as
a headline feature then it should be to inform people that
partitioning is generally more useable with larger numbers of
partitions, not just that SELECT/UPDATE/DELETE now perform better when
pruning many partitions. The work done there and what's done to speed
up tuple routing in INSERT/COPY both complement each other, so they're
likely good to keep as one in the headline features list. Mentioning
one without the other might leave some people guessing about if we've
addressed the other deficiencies with partitioning performance.
Sadly, they can't refer to the release notes for more information
since they don't detail what's changed in this area :(

--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Amit Langote-2
Hi David,

On 2019/05/15 11:59, David Rowley wrote:
> Sadly, they can't refer to the release notes for more information
> since they don't detail what's changed in this area :(

Bruce seemed to insist on summarizing all the performance-related
improvements into one item.  Initial wording mentioned just pruning, which
after some back and forth has finally been turned into:

  Improve performance of many operations on partitioned tables
  (Amit Langote, David Rowley, Tom Lane, Álvaro Herrera)

  Tables with thousands of child partitions can now be processed
  efficiently by operations that only need to touch a small number of
  partitions.

I hear you saying that the description may be too vague *for release
notes* even though it now covers *all* the performance improvements made
to address the use cases where small number of partitions are touched.
Maybe, you're saying that we should've mentioned individual items
(partition pruning, tuple routing, etc.) at least in the release notes,
which I did suggest on -committers [1], but maybe Bruce didn't think it
was necessary to list up individual items.

That leaves a few other commits mentioned in the release-12.sgml next to
this item that are really not related to this headline description, which
both you and I have pointed out in different threads [2][3], but I haven't
really caught Bruce's position about them.

Thanks,
Amit

[1]
https://www.postgresql.org/message-id/d5267ae5-bd4a-3e96-c21b-56bfa9fec7e8%40lab.ntt.co.jp

[2]
https://www.postgresql.org/message-id/3f0333be-fd32-55f2-9817-5853a6bbd233%40lab.ntt.co.jp

[3]
https://www.postgresql.org/message-id/CAKJS1f8R6DC45bauzeGF-QMaQ90B_NFSJB9mvVOuhKVDkajehg%40mail.gmail.com



Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Bruce Momjian
On Wed, May 15, 2019 at 05:36:32PM +0900, Amit Langote wrote:

> Hi David,
>
> On 2019/05/15 11:59, David Rowley wrote:
> > Sadly, they can't refer to the release notes for more information
> > since they don't detail what's changed in this area :(
>
> Bruce seemed to insist on summarizing all the performance-related
> improvements into one item.  Initial wording mentioned just pruning, which
> after some back and forth has finally been turned into:
>
>   Improve performance of many operations on partitioned tables
>   (Amit Langote, David Rowley, Tom Lane, Álvaro Herrera)
>
>   Tables with thousands of child partitions can now be processed
>   efficiently by operations that only need to touch a small number of
>   partitions.
>
> I hear you saying that the description may be too vague *for release
> notes* even though it now covers *all* the performance improvements made
> to address the use cases where small number of partitions are touched.
> Maybe, you're saying that we should've mentioned individual items
> (partition pruning, tuple routing, etc.) at least in the release notes,
> which I did suggest on -committers [1], but maybe Bruce didn't think it
> was necessary to list up individual items.
>
> That leaves a few other commits mentioned in the release-12.sgml next to
> this item that are really not related to this headline description, which
> both you and I have pointed out in different threads [2][3], but I haven't
> really caught Bruce's position about them.

I think the more specific we make the partition description, the more
limited it will appear to be.  I think almost all partition operations
will appear to be faster with PG 12, even if users can't articulate
exactly why.

--
  Bruce Momjian  <[hidden email]>        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 +


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Alvaro Herrera-9
On 2019-May-16, Bruce Momjian wrote:

> I think the more specific we make the partition description, the more
> limited it will appear to be.  I think almost all partition operations
> will appear to be faster with PG 12, even if users can't articulate
> exactly why.

I don't understand why you want to make things such black boxes.  It is
what it is, and some users (not all) will want to understand.  People
who have already tested pg11 and found it insufficient may give pg12 a
second look if we tell them we have fixed the deficiencies they found.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Diego-2

On 2019-05-16 16:08, Alvaro Herrera wrote:

> On 2019-May-16, Bruce Momjian wrote:
>
>> I think the more specific we make the partition description, the more
>> limited it will appear to be.  I think almost all partition operations
>> will appear to be faster with PG 12, even if users can't articulate
>> exactly why.
> I don't understand why you want to make things such black boxes.  It is
> what it is, and some users (not all) will want to understand.  People
> who have already tested pg11 and found it insufficient may give pg12 a
> second look if we tell them we have fixed the deficiencies they found.

yep, I agree with Alvaro, I'm one of these users...




Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Peter Geoghegan-4
In reply to this post by Alvaro Herrera-9
On Thu, May 16, 2019 at 12:08 PM Alvaro Herrera
<[hidden email]> wrote:
> I don't understand why you want to make things such black boxes.  It is
> what it is, and some users (not all) will want to understand.  People
> who have already tested pg11 and found it insufficient may give pg12 a
> second look if we tell them we have fixed the deficiencies they found.

+1. The major features list should be accessible, but otherwise I
think that we should add more detail.

80% - 90% of the items listed in the release notes aren't interesting
to users, but *which* 80% - 90% it is varies. The release notes don't
have to function as a press release, because we'll have an actual
press release instead.

--
Peter Geoghegan


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Michael Paquier-2
On Thu, May 16, 2019 at 12:35:25PM -0700, Peter Geoghegan wrote:
> On Thu, May 16, 2019 at 12:08 PM Alvaro Herrera <[hidden email]> wrote:
>> I don't understand why you want to make things such black boxes.  It is
>> what it is, and some users (not all) will want to understand.  People
>> who have already tested pg11 and found it insufficient may give pg12 a
>  second look if we tell them we have fixed the deficiencies they found.
>
> +1. The major features list should be accessible, but otherwise I
> think that we should add more detail.

+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.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Peter Geoghegan-4
On Thu, May 16, 2019 at 4:52 PM Michael Paquier <[hidden email]> 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.

--
Peter Geoghegan


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Bruce Momjian
In reply to this post by Alvaro Herrera-9
On Thu, May 16, 2019 at 03:08:06PM -0400, Alvaro Herrera wrote:

> On 2019-May-16, Bruce Momjian wrote:
>
> > I think the more specific we make the partition description, the more
> > limited it will appear to be.  I think almost all partition operations
> > will appear to be faster with PG 12, even if users can't articulate
> > exactly why.
>
> I don't understand why you want to make things such black boxes.  It is
> what it is, and some users (not all) will want to understand.  People
> who have already tested pg11 and found it insufficient may give pg12 a
> second look if we tell them we have fixed the deficiencies they found.

The release notes are written so it is clear to the average reader, and
is as short as it can be while remaining clear.  If there is some other
criteria the community wants to use, I suggest you start a thread on the
hackers list.

--
  Bruce Momjian  <[hidden email]>        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 +


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Bruce Momjian
In reply to this post by Michael Paquier-2
On Fri, May 17, 2019 at 08:52:50AM +0900, Michael Paquier wrote:

> On Thu, May 16, 2019 at 12:35:25PM -0700, Peter Geoghegan wrote:
> > On Thu, May 16, 2019 at 12:08 PM Alvaro Herrera <[hidden email]> wrote:
> >> I don't understand why you want to make things such black boxes.  It is
> >> what it is, and some users (not all) will want to understand.  People
> >> who have already tested pg11 and found it insufficient may give pg12 a
> >  second look if we tell them we have fixed the deficiencies they found.
> >
> > +1. The major features list should be accessible, but otherwise I
> > think that we should add more detail.
>
> +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.

What changes in the current description would cause people not to retest
to see if it is better?  If anything, the description is too broad.

--
  Bruce Momjian  <[hidden email]>        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 +


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Bruce Momjian
In reply to this post by Peter Geoghegan-4
On Thu, May 16, 2019 at 05:05:13PM -0700, Peter Geoghegan wrote:

> On Thu, May 16, 2019 at 4:52 PM Michael Paquier <[hidden email]> 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  <[hidden email]>        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 +


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Peter Geoghegan-4
On Thu, May 16, 2019 at 6:32 PM Bruce Momjian <[hidden email]> wrote:
> 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.

I don't think that making it possible to read the release notes from
start to finish is a useful goal. Users probably just skim them. I
certainly don't read them from start to finish, nor do I expect to
understand every item.

> We have already adjusted the partition item, and the btree item.

I was making a general point. This comes up every year.

> 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.

I think that it should be discussed at the developer meeting.

--
Peter Geoghegan


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Bruce Momjian
On Thu, May 16, 2019 at 06:49:29PM -0700, Peter Geoghegan wrote:
> On Thu, May 16, 2019 at 6:32 PM Bruce Momjian <[hidden email]> wrote:
> > 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.
>
> I don't think that making it possible to read the release notes from
> start to finish is a useful goal. Users probably just skim them. I
> certainly don't read them from start to finish, nor do I expect to
> understand every item.

I think we expect people to read them fully because how would they know
what changed and what new features were added.  I do think allowing more
detail by showing the commit messages would be helpful for people who
want to drill down on an item.

> > We have already adjusted the partition item, and the btree item.
>
> I was making a general point. This comes up every year.
>
> > 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.
>
> I think that it should be discussed at the developer meeting.

OK, that makes sense.

--
  Bruce Momjian  <[hidden email]>        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 +


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Alvaro Herrera-9
In reply to this post by Bruce Momjian
On 2019-May-16, Bruce Momjian wrote:

> The release notes are written for the _average_ reader.

I disagree with this assertion, and frankly I cannot understand why you
think that's the most useful thing to do.  The release notes are not a
press release, where you have to make things pretty or understandable to
everyone.  Users can skip items they don't understand or don't care
about; but would at least be given the option.  If we don't document,
we're making the decision for them that they must not care.

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL 12: Feature Highlights

Michael Paquier-2
In reply to this post by Bruce Momjian
On Thu, May 16, 2019 at 10:21:35PM -0400, Bruce Momjian wrote:
> I think we expect people to read them fully because how would they know
> what changed and what new features were added.  I do think allowing more
> detail by showing the commit messages would be helpful for people who
> want to drill down on an item.

This point is interesting.  The release notes include in the sgml
sources references to the related commits.  Could it make sense to
have links to the main commits of a feature which can be clicked on
directly from the html docs or such?  I understand that producing the
notes is a daunting task already, and Bruce does an awesome job.  Just
wondering if we could make that automated in some way if that helps
with the user experience...  Anyway, this is unrelated to the topic of
this thread.  My apologies for the digression.
--
Michael

signature.asc (849 bytes) Download Attachment
1234