Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Sep 22, 2021 at 6:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I thought the point about FDWs was important because actual work (by
>> FDW authors) is needed to make anything happen. The extra parallelism
>> inside plpgsql functions doesn't require user effort, so I don't see
>> that it needs to be called out separately.
> True, but I'm willing to guess we have a lot more people who are using
> stored procs with return query and who are going to be very happy
> about them now being much faster in cases where parallelism worked,
> than we have people who are writing FDWs..
Certainly. But my sentence about "Numerous performance improvements"
already mashes down dozens of other it-just-works-better-now
performance improvements. Wny call out that one in particular?
If I had to pick out just one, I might actually lean towards mentioning
86dc90056, which might change users' calculus about how many partitions
they can use. (But I may be biased about that.)
> My take on that is audience. It's an important feature for existing
> users of PostgreSQL, and an important change over how the system
> behaved before. They are more likely to read the release notes. The
> press release is more about reaching people who are not already using
> postgres, or who are so but more tangentially.
Perhaps, but on those grounds, the business about reducing B-tree bloat
doesn't belong in the press release either. Anyway I'm not sure the
audiences are so different --- if I thought they were, I'd not have
started from the press release.
My feeling is that the initial summary in the release notes is meant
to be a 10000-meter overview of what's new in the release. As soon
as you get past that bullet list, you find yourself right down in the
weeds, so an overview is good to have. The press release can afford
to fly a little lower than 10000 meters, though not by all that much.
regards, tom lane