Re: PG 12 draft release notes

Hi,

Note that I've added a few questions to individuals involved with
specific points. If you're in the To: list, please search for your name.


On 2019-05-11 16:33:24 -0400, Bruce Momjian wrote:
> I have posted a draft copy of the PG 12 release notes here:
>
> 	http://momjian.us/pgsql_docs/release-12.html
> They are committed to git.

Thanks!

  Migration to Version 12

There's a number of features in the compat section that are more general
improvements with a side of incompatibility. Won't it be confusing to
e.g. have have the ryu floating point conversion speedups in the compat
section, but not in the "General Performance" section?


     
      Remove the special behavior of OID columns (Andres Freund,
      John Naylor)
     

Should we mention that tables with OIDs have to have their oids removed
before they can be upgraded?


     
      Refactor geometric
      functions and operators (Emre Hasegeli)
     

     
      This could lead to more accurate, but slightly different, results
      from previous releases.
     
    
    


     
      Restructure geometric
      types to handle NaN, underflow, overflow and division by
      zero more consistently (Emre Hasegeli)
     
    

    


     
      Improve behavior and error reporting for the line data type (Emre Hasegeli)
     
    

Is that sufficient explanation? Feels like we need to expand a bit
more. In particular, is it possible that a subset of the changes here
require reindexing?

Also, aren't three different entries a bit too much?


     
      Avoid performing unnecessary rounding of REAL and DOUBLE
      PRECISION values (Andrew Gierth)
     

     
      This dramatically speeds up processing of floating-point
      values but causes additional trailing digits to
      potentially be displayed.  Users wishing to have output
      that is rounded to match the previous behavior can set extra_float_digits=0,
      which is no longer the default.
     
    

Isn't it exactly the *other* way round? *Previously* we'd output
additional trailing digits. The new algorithm instead will instead have
*exactly* the required number of digits?


      


       
        Improve handling of partition dependency (Tom Lane)
       

       
        This prevents the creation of inconsistent partition hierarchies
        in rare cases.
       
      

That seems not very informative for users?


      


       
        Improve speed of btree index insertions (Peter Geoghegan,
        Alexander Korotkov)
       

       
        The new code improves the space-efficiency of page splits,
        reduces locking overhead, and gives better performance for
        UPDATEs and DELETEs on
        indexes with many duplicates.
       
      

      


       
        Have new btree indexes sort duplicate index entries in heap-storage
        order (Peter Geoghegan, Heikki Linnakangas)
       

       
        Indexes pg_upgraded from previous
        releases will not have this ordering.
       
      

I'm not sure that the grouping here is quite right. And the second entry
probably should have some explanation about the benefits?


      


       
        Reduce locking requirements for index renaming (Peter Eisentraut)
       
      

Should we specify the newly required lock level? Because it's quire
relevant for users what exactly they're now able to do concurrently in
operation?


       
        Allow common table expressions
        (CTE) to be inlined in later parts of the query
        (Andreas Karlsson, Andrew Gierth, David Fetter, Tom Lane)
       

       
        Specifically, CTEs are inlined
        if they are not recursive and are referenced only
        once later in the query.  Inlining can be prevented by
        specifying MATERIALIZED, and forced by
        specifying NOT MATERIALIZED.  Previously,
        CTEs were never inlined and were always
        evaluated before the rest of the query.
       

Hm. Is it actually correct to say that "were always evaluated before the
rest of the query."? My understanding is that that's not actually how
they behaved. Materialization for CTE scans was on-demand (i.e. when
needed by a CTE scan), and even for DML CTEs we'd only force the
underlying query to completion at the end of the query?



      


       
        Add support for function
        selectivity (Tom Lane)
       
      

Hm, that message doesn't seem like an accurate description of that
commit (if anything it's a391ff3c?). Given that it all requires C
hackery, perhaps we ought to move it to the source code section? And
isn't the most important part of this set of changes

commit 74dfe58a5927b22c744b29534e67bfdd203ac028
Author: Tom Lane 
Date:   2019-02-11 21:26:08 -0500

    Allow extensions to generate lossy index conditions.


      


       
        Greatly reduce memory consumption of 
        and function calls (Andres Freund, Tomas Vondra, Tom Lane)
       
      

Grouping these three changes together makes no sense to me.

I think the first commit just ought not to be mentioned separately, it's
just a fix for a memory leak in 31f3817402, essentially a 12 only bugfix?

The second commit is about position() etc, which seems not to match that
description either?

The third is probably more appropriate to be in the source code
section. While it does speed up function calls a bit (in particular
plpgsql which is very function call heavy), it also is a breaking change
for some external code? Not sure why Tom is listed with this entry?


      


       
        Improve search performance for multi-byte characters (Heikki
        Linnakangas)
       
      

That's the second reference to the commit. I suspect this is much better
separate, so I'd just remove it from above.


      


       
        Allow TOAST
        values to be minimally decompressed (Paul Ramsey)
       

I'd s/minimal/partial/ - I don't think the code guarantees anything
about it being minimal? And "minimally decompressed" also is somewhat
confusing, because it sounds like it's about the compression quality
rather than only decompressing part of the data.


      


       
        Prevent  from requesting a lock on
        tables for which it lacks permission (Michaël Paquier)
       

       
        This prevents unauthorized locking delays.
       
      

      


       
        Prevent VACUUM and ANALYZE
        from requesting a lock on tables for which it lacks permission
        (Michaël Paquier)
       

       
        This prevents unauthorized locking delays.
       
      


I don't think this should be in the <acronym>Authentication</acronym>
section.

Also perhaps, s/it/the user/, or "the caller"?


      


       
        Reduce the default value of  to 2ms (Tom Lane)
       
      

I think this needs to explain that this can increase autovacuum's IO
throughput considerably.

      


       
        Allow  to specify
        sub-millisecond delays (Tom Lane)
       

       
        Floating-point values can also now be specified.
       
      

And this should be merged with the previous entry?


      


       
        Allow time-based server variables to use micro-seconds (us) (Tom Lane)
       
      

      


       
        Allow fractional input for integer server variables (Tom Lane)
       

       
        For example, SET work_mem = '30.1GB'.
       
      

      


       
        Allow units to be specified for floating-point server variables
        (Tom Lane)
       
      

Can't we combine these? Seems excessively detailed in comparison to the
rest of the entries.


     


      
       Add an explicit value of current for  (Peter Eisentraut)
      
     

Seems like this should be combined with the earlier "Cause recovery to
advance to the latest timeline by default" entry.


     


      
       Add support for generated
       columns (Peter Eisentraut)
      

      
       Rather than storing a value only at row creation time, generated
       columns are also modified during updates, and can reference other
       table columns.
      
     

I find this description confusing. How about cribbing from the commit?
Roughly like

    This allows creating columns that are computed from expressions,
    including references to other columns in the same table, rather than
    having to be specified by the inserter/updater.

Think we also ought to mention that this is only stored generated
columns, given that the SQL feature also includes virtual columns?


     


      
       Add  and CREATE
       TABLE options to prevent VACUUM
       from truncating trailing empty pages (Tsunakawa Takayuki)
      

      
       The options are vacuum_truncate and
       toast.vacuum_truncate.  This reduces vacuum
       locking requirements.
      
     

Maybe add something like: "This can be helpful to avoid query
cancellations on standby that are not avoided by hot_standby_feedback."?


     


      
       Allow vacuum to avoid index cleanup with the
       INDEX_CLEANUP option (Masahiko Sawada)
      
     

I think we ought to expand a bit more on why one would do that,
including perhaps some caveat?


     


      
       Allow modifications of system tables using  (Peter Eisentraut)
      

      
       This allows modifications of reloptions and
       autovacuum settings.
      
     

I think the first paragraph is a bit dangerous. This does *not*
generally allow modifications of system tables using ALTER TABLE.


     


      
       Allow RECORD and RECORD[] to be specified
       as a function return-value
       record (Elvis Pranskevichus)
      

      
       DETAIL?
      
     

This description doesn't sound accurate to me. Tom?


      


       
        Compute behavior based on pgbench's 
        value more precisely (Tom Lane)
       
      

"Computing behavior" sounds a bit odd. Maybe "Improve precision of
pgbench's " option?


      


       
        Allow restoration of an INSERT-statement dump
        to skip rows which would cause conflicts (Surafel Temesgen)
       

       
        The pg_dump option is
        .
       
      

Hm, this doesn't seem that clear. It's not really a restoration time
option, and it sounds a bit like that in the above. How about instead saying something
like:
Allow pg_dump to emit INSERT ... ON CONFLICT DO NOTHING (Surafel).


      


       
        Allow the number of float digits to be specified
        for pg_dump and
        pg_dumpall (Andrew Dunstan)
       

       
        This allows the float digit output to match previous dumps.
       

Hm, feels like that should be combined with the ryu compat entry?


      
       Add  command to create
       new table types (Haribabu Kommi, Andres Freund, Álvaro Herrera,
       Dimitri Dolgov)
      

A few points:

1) Is this really source code, given that CREATE ACCESS METHOD TYPE
   TABLE is a DDL command, and USING (...) for CREATE TABLE etc is an
   option to DDL commands?

2) I think the description sounds a bit too much like it's about new
   forms of tables, rather than their storage. How about something
   roughly like:

   Allow different table access methods</> to be
   used</>. This allows to develop and
   use new ways of storing and accessing table data, optimized for
   different use-cases, without having to modify
   PostgreSQL. The existing heap access method
   remains the default.

3) This misses a large set of commits around making tableam possible, in
   particular the commits around

commit 4da597edf1bae0cf0453b5ed6fc4347b6334dfe1
Author: Andres Freund 
Date:   2018-11-16 16:35:11 -0800

    Make TupleTableSlots extensible, finish split of existing slot type.

   Given that those commits entail an API break relevant for extensions,
   should we have them as a separate "source code" note?

4) I think the attribution isn't quite right. For one, a few names with
   substantial work are missing (Amit Khandekar, Ashutosh Bapat,
   Alexander Korotkov), and the order doesn't quite seem right. On the
   latter part I might be somewhat petty, but I spend *many* months of
   my life on this.

   How about:
   Andres Freund, Haribabu Kommi, Alvaro Herrera, Alexander Korotkov, David Rowley, Dimitri Golgov
   if we keep 3) separate and
   Andres Freund, Haribabu Kommi, Alvaro Herrera, Ashutosh Bapat, Alexander Korotkov, Amit Khandekar, David Rowley, Dimitri Golgov
   otherwise?

   I think it might actually make sense to take David off this list,
   because his tableam work is essentially part of it's own entry, as


       
        Improve speed of COPY into partitioned tables
        (David Rowley)
       

   since his copy.c portions of 86b85044e823a largely are a rewrite of
   the above commit.


     


      
       Document that the B/bytes units can be specified
       for server variables
       (Greg Stark)
      
     

Given how large changes we skip over in the release notes, I don't
really see a point in including changes like this. Feels like we'd at
the very least also have to include larger changes with typo/grammar
fixes etc?

Greetings,

Andres Freund