On Sat, May 9, 2020 at 11:16 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Tue, May 5, 2020 at 8:46 AM Bruce Momjian <br...@momjian.us> wrote: > > > > I have committed the first draft of the PG 13 release notes. You can > > see them here: > > > > https://momjian.us/pgsql_docs/release-13.html > > > > Thanks for the work. I was today going through the release notes and > was wondering whether we should consider adding information about some > other work done for PG13. > 1. We have allowed an (auto)vacuum to display additional information > about heap or index in case of an error in commit b61d161c14 [1]. > Now, in general, it might not be worth saying much about error > information but I think this one could help users in case they have > some corruption. For example, if one of the indexes on a relation has > some corrupted data (due to bad hardware or some bug), it will let the > user know the index information, and the user can take appropriate > action like either Reindex or maybe drop and recreate the index to > overcome the problem. > 2. In the "Source Code" section, we can add information about > infrastructure enhancement for parallelism. Basically, "Allow > relation extension and page lock to conflict among parallel-group > members" [2][3]. This will allow improving the parallelism further in > many cases like (a) we can allow multiple workers to operate on a heap > and index in a parallel vacuum, (b) we can allow parallel Inserts, > etc. >
One more observation: Allow inserts to trigger autovacuum activity (Laurenz Albe, Darafei Praliaskouski) This new behavior allows pages to be set as all-visible, which then allows index-only scans, ... The above sentence sounds to mean that this feature allows index-only scans in more number of cases after this feature. Is that what you intend to say? If so, is that correct? Because I think this will allow index-only scans to skip "Heap Fetches" in more cases. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com