Postgres 11 release notes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
253 messages Options
123456 ... 13
Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
On Sun, May 13, 2018 at 04:55:35PM +0530, Amit Kapila wrote:

> On Sun, May 13, 2018 at 4:40 PM, Amit Kapila <[hidden email]> wrote:
> > On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <[hidden email]> wrote:
> >> I have committed the first draft of the Postgres 11 release notes.  I
> >> will add more markup soon.  You can view the most current version here:
> >>
> >>         http://momjian.us/pgsql_docs/release-11.html
> >>
> >> I expect a torrent of feedback.  ;-)
> >>
> >
> > Thanks for compiling the first draft.
> >
>
> One more comment on below item:
>
> Allow entire hash index pages to be scanned (Ashutosh Sharma)
>
> Previously each hash index entry has to be locked and scanned separately.
>
> I think it is better to write the second line as "Previously for each
> hash index entry, we need to refind the scan position within the page
> and cuts down on lock/unlock traffic.".

Nice, done.

--
  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: Postgres 11 release notes

Bruce Momjian
In reply to this post by Andrew Dunstan-8
On Mon, May 14, 2018 at 07:47:54AM -0400, Andrew Dunstan wrote:

>
>
> On 05/12/2018 08:47 PM, Bruce Momjian wrote:
> > On Sat, May 12, 2018 at 01:22:55PM -0700, Peter Geoghegan wrote:
> >> On Fri, May 11, 2018 at 2:06 PM, Bruce Momjian <[hidden email]> wrote:
> >>> Done and URL updated.
> >> I have some feedback on "Allow NOT NULL to be added to columns without
> >> requiring a table rewrite". I suggest that this be phrased as "Avoid a
> >> table rewrite when ALTER TABLE ADD COLUMN sets a default value for a
> >> column". Referencing the fact that Postgres was previously able to do
> >> this with a NULL default doesn't seem to add anything.
> > Agreed, done:
> >
> >         Allow <command>ALTER TABLE</command> to add a non-null default
> >         column without a table rewrite (Andrew Dunstan, Serge Rielau)
> >
>
>
> I think "a column with a non-null default" would be a bit clearer than
> "a non-null default column".

Yeah, I didn't like what I had either, so I changed it to what you
suggested, though it gives us an odd "with X, without Y" pattern:

        Allow <command>ALTER TABLE</command> to add a column with
        a non-null default without a table rewrite (Andrew Dunstan,
        Serge Rielau)

--
  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: Postgres 11 release notes

Bruce Momjian
In reply to this post by Dilip Kumar-2
On Mon, May 14, 2018 at 05:34:54PM +0530, Dilip Kumar wrote:

>
> On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <[hidden email]> wrote:
>
>     I have committed the first draft of the Postgres 11 release notes.  I
>     will add more markup soon.  You can view the most current version here:
>
>             http://momjian.us/pgsql_docs/release-11.html
>
>     I expect a torrent of feedback.  ;-)
>
>     On a personal note, I want to apologize for not adequately championing
>     two features that I think have strategic significance but didn't make it
>     into Postgres 11:  parallel FDW access and improved multi-variate
>     statistics.  I hope to do better job during Postgres 12.
>    
>     --
>       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 +
>
>
>
> I think the below commit is missed in the release notes?
>
> 5edc63bda68a77c4d38f0cbeae1c4271f9ef4100
>
> Committer: Robert Haas <[hidden email]>  2017-11-10 13:50:50
>
>     Account for the effect of lossy pages when costing bitmap scans.
>     
>     Dilip Kumar, reviewed by Alexander Kumenkov, Amul Sul, and me.
>     Some final adjustments by me.
>
> As part of this commit, we are also accounting for the lossy pages during
> bitmap costing.  This will consider
> the effect of work_mem while selecting the bitmap heap scan path.

Uh, that seems very exotic to mention, sorry.  Others have opinions?

I have updated the PG11 doc URL with all the changes so far.

--
  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: Postgres 11 release notes

Michael Paquier-2
In reply to this post by Bruce Momjian
On Mon, May 14, 2018 at 04:04:58PM -0400, Bruce Momjian wrote:
> So, channel binding has had me confused since I first heard about it.  I
> have done some research and reworded the commit with the attached
> first patch.

pg11.diff looks roughly fine to me.

> Also, I have created a second patch which actually explains the two
> SCRAM channel binding options and how the work.

+         The list of channel binding types supported by the server are
+         listed in <xref linkend="sasl-authentication"/>.  An empty value
+         specifies that the client will not use channel binding.  If this
+         parameter is not specified, <literal>tls-unique</literal> is used,
+         if supported by both server and client.

OK, that's simple enough for users, and we talk about the libpq
parameter here.

The second paragraph is also a nice addition.  You really looked at this
stuff!

> One question I do have is how do we prevent a fake server in the middle
> from pretending it is a PG 10 server and therefore avoiding channel
> binding protections?  I don't see any channel binding options in
> pg_hba.conf, and while libpq has options, they are explained with "This
> parameter is mainly intended for protocol testing."

The answer is that you cannot do that now, as much as you cannot have a
client forbid connection attempt if the client requests SCRAM but the
server downgrades to MD5.  I had a topic on the matter at an unconf
session at the last PGAsia, and except for administrators which forgot
to upgrade a set of servers that was not something worth complicating
the code for, at least that's the conclusion which came out of the
session.  At the end, this is not actually something that you would
control from the server if you care about security, but something which
is controlled from the client.  The limitations that we have know are
partially due to the way libpq handles the authentication protocol.
Hence if you want to prevent servers attempting to do downgrades, you
need options like sslmode saying those things from the client point of
view:
- I want SCRAM, but refuse connection request if server attempts MD5 or
something else.
- I want SCRAM and channel binding, but refuse connection request if
server does not advertise channel binding to the client.

There may be value to an server side parameter which forces clients to
use channel binding even if the server has advertized the channel
binding SASL mechanism, and even if connection is made with SSL, but
that's not a downgrade-attack prevention.
--
Michael

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

Re: Postgres 11 release notes

Tatsuo Ishii-3
In reply to this post by Bruce Momjian
Hi Bruce,

> I have committed the first draft of the Postgres 11 release notes.  I
> will add more markup soon.  You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback.  ;-)

I could not find this:

$ git log -1 f8e5f15
commit f8e5f156b30efee5d0038b03e38735773abcb7ed
Author: Andres Freund <[hidden email]>
Date:   Mon Sep 18 19:36:44 2017 -0700

    Rearm statement_timeout after each executed query.
   
    Previously statement_timeout, in the extended protocol, affected all
    messages till a Sync message.  For clients that pipeline/batch query
    execution that's problematic.
   
    Instead disable timeout after each Execute message, and enable, if
    necessary, the timer in start_xact_command(). As that's done only for
    Execute and not Parse / Bind, pipelining the latter two could still
    cause undesirable timeouts. But a survey of protocol implementations
    shows that all drivers issue Sync messages when preparing, and adding
    timeout rearming to both is fairly expensive for the common parse /
    bind / execute sequence.
   
    Author: Tatsuo Ishii, editorialized by Andres Freund
    Reviewed-By: Takayuki Tsunakawa, Andres Freund
    Discussion: https://postgr.es/m/20170222.115044.1665674502985097185.t-ishii@...

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
In reply to this post by Michael Paquier-2
On Tue, May 15, 2018 at 08:10:20AM +0900, Michael Paquier wrote:

> On Mon, May 14, 2018 at 04:04:58PM -0400, Bruce Momjian wrote:
> > So, channel binding has had me confused since I first heard about it.  I
> > have done some research and reworded the commit with the attached
> > first patch.
>
> pg11.diff looks roughly fine to me.
>
> > Also, I have created a second patch which actually explains the two
> > SCRAM channel binding options and how the work.
>
> +         The list of channel binding types supported by the server are
> +         listed in <xref linkend="sasl-authentication"/>.  An empty value
> +         specifies that the client will not use channel binding.  If this
> +         parameter is not specified, <literal>tls-unique</literal> is used,
> +         if supported by both server and client.
>
> OK, that's simple enough for users, and we talk about the libpq
> parameter here.

Great, committed.

> The second paragraph is also a nice addition.  You really looked at this
> stuff!

Committed too.

Yeah, it bugs me when I hear terms thrown around but can't get to the
details of what is happening.  This PDF unlocked it for me:

        http://www.manulis.eu/papers/MaStDe_SSR14.pdf

> > One question I do have is how do we prevent a fake server in the middle
> > from pretending it is a PG 10 server and therefore avoiding channel
> > binding protections?  I don't see any channel binding options in
> > pg_hba.conf, and while libpq has options, they are explained with "This
> > parameter is mainly intended for protocol testing."
>
> The answer is that you cannot do that now, as much as you cannot have a
> client forbid connection attempt if the client requests SCRAM but the
> server downgrades to MD5.  I had a topic on the matter at an unconf
> session at the last PGAsia, and except for administrators which forgot
> to upgrade a set of servers that was not something worth complicating
> the code for, at least that's the conclusion which came out of the
> session.  At the end, this is not actually something that you would
> control from the server if you care about security, but something which
> is controlled from the client.  The limitations that we have know are
> partially due to the way libpq handles the authentication protocol.
> Hence if you want to prevent servers attempting to do downgrades, you
> need options like sslmode saying those things from the client point of
> view:
> - I want SCRAM, but refuse connection request if server attempts MD5 or
> something else.
> - I want SCRAM and channel binding, but refuse connection request if
> server does not advertise channel binding to the client.

Agreed.  The libpq parameters don't help, I assume.

> There may be value to an server side parameter which forces clients to
> use channel binding even if the server has advertised the channel
> binding SASL mechanism, and even if connection is made with SSL, but
> that's not a downgrade-attack prevention.

What TLS does is to mix the offered ciphers into the negotiation hash so
a man-in-the-middle can't pretend it doesn't support something.  Could
we do something like that here?

I have to question the value of man-in-the-middle protection that is so
easily bypassed.

--
  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: Postgres 11 release notes

Bruce Momjian
In reply to this post by Tatsuo Ishii-3
On Tue, May 15, 2018 at 09:19:04AM +0900, Tatsuo Ishii wrote:

> Hi Bruce,
>
> > I have committed the first draft of the Postgres 11 release notes.  I
> > will add more markup soon.  You can view the most current version here:
> >
> > http://momjian.us/pgsql_docs/release-11.html
> >
> > I expect a torrent of feedback.  ;-)
>
> I could not find this:
>
> $ git log -1 f8e5f15
> commit f8e5f156b30efee5d0038b03e38735773abcb7ed
> Author: Andres Freund <[hidden email]>
> Date:   Mon Sep 18 19:36:44 2017 -0700
>
>     Rearm statement_timeout after each executed query.
>    
>     Previously statement_timeout, in the extended protocol, affected all
>     messages till a Sync message.  For clients that pipeline/batch query
>     execution that's problematic.
>    
>     Instead disable timeout after each Execute message, and enable, if
>     necessary, the timer in start_xact_command(). As that's done only for
>     Execute and not Parse / Bind, pipelining the latter two could still
>     cause undesirable timeouts. But a survey of protocol implementations
>     shows that all drivers issue Sync messages when preparing, and adding
>     timeout rearming to both is fairly expensive for the common parse /
>     bind / execute sequence.
>    
>     Author: Tatsuo Ishii, editorialized by Andres Freund
>     Reviewed-By: Takayuki Tsunakawa, Andres Freund
>     Discussion: https://postgr.es/m/20170222.115044.1665674502985097185.t-ishii@...

That seemed too detailed for the release notes.  Is that wrong?

--
  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: Postgres 11 release notes

Tatsuo Ishii-3
>> I could not find this:
>>
>> $ git log -1 f8e5f15
>> commit f8e5f156b30efee5d0038b03e38735773abcb7ed
>> Author: Andres Freund <[hidden email]>
>> Date:   Mon Sep 18 19:36:44 2017 -0700
>>
>>     Rearm statement_timeout after each executed query.
>>    
>>     Previously statement_timeout, in the extended protocol, affected all
>>     messages till a Sync message.  For clients that pipeline/batch query
>>     execution that's problematic.
>>    
>>     Instead disable timeout after each Execute message, and enable, if
>>     necessary, the timer in start_xact_command(). As that's done only for
>>     Execute and not Parse / Bind, pipelining the latter two could still
>>     cause undesirable timeouts. But a survey of protocol implementations
>>     shows that all drivers issue Sync messages when preparing, and adding
>>     timeout rearming to both is fairly expensive for the common parse /
>>     bind / execute sequence.
>>    
>>     Author: Tatsuo Ishii, editorialized by Andres Freund
>>     Reviewed-By: Takayuki Tsunakawa, Andres Freund
>>     Discussion: https://postgr.es/m/20170222.115044.1665674502985097185.t-ishii@...
>
> That seemed too detailed for the release notes.  Is that wrong?

This commit gives user-visible changes to the statment timeout
behavior. So I think this should be added to the release notes.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

bocap
In reply to this post by Bruce Momjian
Hi,

2018/05/15 5:28、Bruce Momjian <[hidden email]>のメール:

> Added:
>
>        Consistently return <literal>NaN</literal> for
>        <literal>NaN</literal> inputs to <function>power()</literal>
>        on older platforms (Dang Minh Huong)

Thank you.


Regards,
—-
Dang Minh Huong
Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

akapila
In reply to this post by Bruce Momjian
On Tue, May 15, 2018 at 2:05 AM, Bruce Momjian <[hidden email]> wrote:

> On Sun, May 13, 2018 at 04:40:19PM +0530, Amit Kapila wrote:
>> On Fri, May 11, 2018 at 8:38 PM, Bruce Momjian <[hidden email]> wrote:
>> > I have committed the first draft of the Postgres 11 release notes.  I
>> > will add more markup soon.  You can view the most current version here:
>> >
>> >         http://momjian.us/pgsql_docs/release-11.html
>> >
>> > I expect a torrent of feedback.  ;-)
>> >
>>
>> Thanks for compiling the first draft.  I think there are few things
>> which we should add to the Parallel Queries section. (a) commit
>> e89a71fb449af2ef74f47be1175f99956cf21524 -
>> Pass InitPlan values to workers via Gather (Merge).  We can write
>> something like "Allow the part of the plan that references an initplan
>> to run in parallel" or  "Parallelise queries containing initplans",
>
> Uh, I need some explaination of what an initplan is
>

See the below comment in the code:
" This module is concerned with executing SubPlan expression nodes,
which should not be confused with sub-SELECTs appearing in FROM.
SubPlans are divided into "initplans", which are those that need only
one evaluation per query (among other restrictions, this requires that
they don't use any direct correlation variables from the parent plan
level), and "regular" subplans, which are re-evaluated every time
their result is required.

> and what type of
> query this helps.
>

Serial-Plan
-----------------
postgres=# explain select * from t1 where t1.k=(select max(k) from t3);
                             QUERY PLAN
--------------------------------------------------------------------
 Seq Scan on t1  (cost=35.51..71.01 rows=10 width=12)
   Filter: (k = $0)
   InitPlan 1 (returns $0)
     ->  Aggregate  (cost=35.50..35.51 rows=1 width=4)
           ->  Seq Scan on t3  (cost=0.00..30.40 rows=2040 width=4)
(5 rows)

Parallel-Plan
--------------------
postgres=# explain select * from t1 where t1.k=(select max(k) from t3);
                                      QUERY PLAN
---------------------------------------------------------------------------------------
 Gather  (cost=9.71..19.38 rows=2 width=12)
   Workers Planned: 2
   Params Evaluated: $1
   InitPlan 1 (returns $1)
     ->  Finalize Aggregate  (cost=9.70..9.71 rows=1 width=4)
           ->  Gather  (cost=9.69..9.70 rows=2 width=4)
                 Workers Planned: 2
                 ->  Partial Aggregate  (cost=9.69..9.70 rows=1 width=4)
                       ->  Parallel Seq Scan on t3  (cost=0.00..8.75
rows=375 width=4)
   ->  Parallel Seq Scan on t1  (cost=0.00..9.67 rows=1 width=12)
         Filter: (k = $1)
(11 rows)

Here, you can observe that initplan itself gets parallelized and the
part of plan tree referring initplan also got parallelized.

The other example from regression test is:

explain (costs off)
select count(*) from tenk1
        where tenk1.unique1 = (Select max(tenk2.unique1) from tenk2);
                      QUERY PLAN
------------------------------------------------------
 Aggregate
   InitPlan 1 (returns $2)
     ->  Finalize Aggregate
           ->  Gather
                 Workers Planned: 2
                 ->  Partial Aggregate
                       ->  Parallel Seq Scan on tenk2
   ->  Gather
         Workers Planned: 4
         Params Evaluated: $2
         ->  Parallel Seq Scan on tenk1
               Filter: (unique1 = $2)
(12 rows)

I can share more examples if required.


>> (b) "Parallelise queries that contains expensive functions in target
>> lists" (Commits - 3f90ec8597c3515e0d3190613b31491686027e4b and
>> 11cf92f6e2e13c0a6e3f98be3e629e6bd90b74d5).
>
> So we generate the entire query before the target list function calls,
> the run another parallel run just for those function calls?
>

No, it is not like that.  We divide the scan among workers and each
worker should perform projection of the rows it scanned (after
applying filter).  Now, if the expensive functions are part of target
lists, then we can push the computation of expensive functions (as
part of target list) in workers which will divide the work.

>  Really?  Do
> we run each column in its own worker or do we split the result set into
> parts and run those in parallel?  How do we know, just the function call
> costs?
>

The function's cost can be determined via pg_proc->procost.  For this
particular case, you can refer the call graph -
create_pathtarget->set_pathtarget_cost_width->cost_qual_eval_node->cost_qual_eval_walker->get_func_cost

>  I can admit I never saw that coming.
>

I think the use case becomes interesting with parallel query because
now you can divide such cost among workers.

Feel free to ask more questions if above doesn't clarify the usage of
these features.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Amit Langote-2
In reply to this post by Bruce Momjian
On 2018/05/15 5:30, Bruce Momjian wrote:

> On Sun, May 13, 2018 at 06:53:26PM +0900, Amit Langote wrote:
>> The following item
>>
>> +<!--
>> +2017-11-23 [05b6ec39d] Show partition info from psql \d+
>> +-->
>> +
>> +       <para>
>> +        Have psql \d+ show a partition count of zero (Amit Langote)
>> +       </para>
>>
>> missed mentioning Ashutosh Bapat as an author.
>
> Added.
>
>> Maybe, the item name and description text could be improved as follows:
>>
>> +       <para>
>> +        Have psql \d+ always show the partition information (Amit
>> Langote, Ashutosh Bapat)
>> +       </para>
>> +
>> +       <para>
>> +        Previously partition information would not be displayed for a
>> partitioned table if
>> +        it had no partitions.  Also indicate which partitions are
>> themselves partitioned.
>> +       </para>
>
> I like it, done.

Thank you.

Regards,
Amit


Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Etsuro Fujita
In reply to this post by Bruce Momjian
(2018/05/12 0:08), Bruce Momjian wrote:

> I have committed the first draft of the Postgres 11 release notes.  I
> will add more markup soon.  You can view the most current version here:
>
> http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback.  ;-)
>
> On a personal note, I want to apologize for not adequately championing
> two features that I think have strategic significance but didn't make it
> into Postgres 11:  parallel FDW access and improved multi-variate
> statistics.  I hope to do better job during Postgres 12.
Thanks for compiling this, Bruce!

I found a copy-pasto in this:

     Below you will find a detailed account of the changes between
     <productname>PostgreSQL</productname> 10 and the previous major
     release.

I think the PG version should be 11, not 10.  Patch attached.

Best regards,
Etsuro Fujita

fix-copy-pasto-in-release-note-11.patch (520 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

David Rowley-3
In reply to this post by Bruce Momjian
On 15 May 2018 at 08:28, Bruce Momjian <[hidden email]> wrote:
>         Consistently return <literal>NaN</literal> for
>         <literal>NaN</literal> inputs to <function>power()</literal>
>         on older platforms (Dang Minh Huong)

While I'm not in favour of removing Dang's credit here, technically
this patch was Tom's. The code added in float.c by Dang's patch
(61b200e2f) was effectively reverted by 6bdf1303.  Dang's regression
tests remain, so should also be credited along with Tom.

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

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

David Rowley-3
In reply to this post by Bruce Momjian
On 12 May 2018 at 03:08, Bruce Momjian <[hidden email]> wrote:
> I have committed the first draft of the Postgres 11 release notes.  I
> will add more markup soon.  You can view the most current version here:
>
>         http://momjian.us/pgsql_docs/release-11.html
>
> I expect a torrent of feedback.  ;-)

I wonder if 3cda10f41bfed -- "Use atomic ops to hand out pages to scan
in parallel scan." should be listed in the notes.

If so, I'd suggest something like:

Improve performance of Parallel Seq Scans with many parallel workers
(David Rowley).

I'd be more inclined to leave it off the notes if the improvement was
marginal, but it was a fairly considerable improvement, per my
benchmarks in [1].

[1] https://www.postgresql.org/message-id/CAKJS1f9tgsPhqBcoPjv9_KUPZvTLCZ4jy%3DB%3DbhqgaKn7cYzm-w@...

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

Reply | Threaded
Open this post in threaded view
|

RE: Postgres 11 release notes

Huong Dangminh
In reply to this post by David Rowley-3
Hi,

> From: David Rowley [mailto:[hidden email]]
> Sent: Tuesday, May 15, 2018 3:01 PM
> To: Bruce Momjian <[hidden email]>
> Cc: Đặng Minh Hướng <[hidden email]>; PostgreSQL-development
> <[hidden email]>
> Subject: Re: Postgres 11 release notes
>
> On 15 May 2018 at 08:28, Bruce Momjian <[hidden email]> wrote:
> >         Consistently return <literal>NaN</literal> for
> >         <literal>NaN</literal> inputs to <function>power()</literal>
> >         on older platforms (Dang Minh Huong)
>
> While I'm not in favour of removing Dang's credit here, technically this
> patch was Tom's. The code added in float.c by Dang's patch
> (61b200e2f) was effectively reverted by 6bdf1303.  Dang's regression tests
> remain, so should also be credited along with Tom.

Thanks David, I agreed.
Also 6bdf1303 should be included like below,

<!--
 Branch: master [6bdf1303b] Avoid wrong results for power() with NaN
+Branch: master [61b200e2f] Avoid wrong results for power() with NaN
 -->
 
        <para>
         Consistently return <literal>NaN</literal> for
         <literal>NaN</literal> inputs to <function>power()</function>
-        on older platforms (Dang Minh Huong)
+        on older platforms (Tom Lane, Dang Minh Huong)
        </para>


Thanks and best regards,
---
Dang Minh Huong
NEC Solution Innovators, Ltd.
http://www.nec-solutioninnovators.co.jp/en/
Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

akapila
In reply to this post by David Rowley-3
On Tue, May 15, 2018 at 11:43 AM, David Rowley
<[hidden email]> wrote:

> On 12 May 2018 at 03:08, Bruce Momjian <[hidden email]> wrote:
>> I have committed the first draft of the Postgres 11 release notes.  I
>> will add more markup soon.  You can view the most current version here:
>>
>>         http://momjian.us/pgsql_docs/release-11.html
>>
>> I expect a torrent of feedback.  ;-)
>
> I wonder if 3cda10f41bfed -- "Use atomic ops to hand out pages to scan
> in parallel scan." should be listed in the notes.
>
> If so, I'd suggest something like:
>
> Improve performance of Parallel Seq Scans with many parallel workers
> (David Rowley).
>

+1 to add this in Release Notes.


--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Tom Lane-2
In reply to this post by David Rowley-3
David Rowley <[hidden email]> writes:
> On 15 May 2018 at 08:28, Bruce Momjian <[hidden email]> wrote:
>> Consistently return <literal>NaN</literal> for
>> <literal>NaN</literal> inputs to <function>power()</literal>
>> on older platforms (Dang Minh Huong)

> While I'm not in favour of removing Dang's credit here, technically
> this patch was Tom's. The code added in float.c by Dang's patch
> (61b200e2f) was effectively reverted by 6bdf1303.  Dang's regression
> tests remain, so should also be credited along with Tom.

I'm not particularly fussed about getting credit for that.  However,
looking again at how that patch series turned out --- ie, that
we ensured POSIX behavior for NaNs only in HEAD --- I wonder
whether we shouldn't do what was mentioned in the commit log for
6bdf1303, and teach numeric_pow() about these same special cases.
It seems like it would be more consistent to change both functions
for v11, rather than letting that other shoe drop in some future
major release.

                        regards, tom lane

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
In reply to this post by akapila
On Tue, May 15, 2018 at 08:45:07AM +0530, Amit Kapila wrote:

> No, it is not like that.  We divide the scan among workers and each
> worker should perform projection of the rows it scanned (after
> applying filter).  Now, if the expensive functions are part of target
> lists, then we can push the computation of expensive functions (as
> part of target list) in workers which will divide the work.
>
> >  Really?  Do
> > we run each column in its own worker or do we split the result set into
> > parts and run those in parallel?  How do we know, just the function call
> > costs?
> >
>
> The function's cost can be determined via pg_proc->procost.  For this
> particular case, you can refer the call graph -
> create_pathtarget->set_pathtarget_cost_width->cost_qual_eval_node->cost_qual_eval_walker->get_func_cost
>
> >  I can admit I never saw that coming.
> >
>
> I think the use case becomes interesting with parallel query because
> now you can divide such cost among workers.
>
> Feel free to ask more questions if above doesn't clarify the usage of
> these features.

OK, I have added the following release note item for both of these:

2017-11-16 [e89a71fb4] Pass InitPlan values to workers via Gather (Merge).
2018-03-29 [3f90ec859] Postpone generate_gather_paths for topmost scan/join rel
2018-03-29 [11cf92f6e] Rewrite the code that applies scan/join targets to paths

        Allow single-evaluation queries, e.g. <literal>FROM</literal>
        clause queries, and functions in the target list to be
        parallelized (Amit Kapila, Robert Haas)

--
  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: Postgres 11 release notes

David Rowley-3
In reply to this post by Tom Lane-2
On 16 May 2018 at 02:01, Tom Lane <[hidden email]> wrote:

> David Rowley <[hidden email]> writes:
>> While I'm not in favour of removing Dang's credit here, technically
>> this patch was Tom's. The code added in float.c by Dang's patch
>> (61b200e2f) was effectively reverted by 6bdf1303.  Dang's regression
>> tests remain, so should also be credited along with Tom.
>
> I'm not particularly fussed about getting credit for that.  However,
> looking again at how that patch series turned out --- ie, that
> we ensured POSIX behavior for NaNs only in HEAD --- I wonder
> whether we shouldn't do what was mentioned in the commit log for
> 6bdf1303, and teach numeric_pow() about these same special cases.
> It seems like it would be more consistent to change both functions
> for v11, rather than letting that other shoe drop in some future
> major release.

I'm inclined to agree. It's hard to imagine these two functions
behaving differently in regards to NaN input is useful to anyone.

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

Reply | Threaded
Open this post in threaded view
|

Re: Postgres 11 release notes

Bruce Momjian
In reply to this post by Tatsuo Ishii-3
On Tue, May 15, 2018 at 09:51:47AM +0900, Tatsuo Ishii wrote:

> >> I could not find this:
> >>
> >> $ git log -1 f8e5f15
> >> commit f8e5f156b30efee5d0038b03e38735773abcb7ed
> >> Author: Andres Freund <[hidden email]>
> >> Date:   Mon Sep 18 19:36:44 2017 -0700
> >>
> >>     Rearm statement_timeout after each executed query.
> >>    
> >>     Previously statement_timeout, in the extended protocol, affected all
> >>     messages till a Sync message.  For clients that pipeline/batch query
> >>     execution that's problematic.
> >>    
> >>     Instead disable timeout after each Execute message, and enable, if
> >>     necessary, the timer in start_xact_command(). As that's done only for
> >>     Execute and not Parse / Bind, pipelining the latter two could still
> >>     cause undesirable timeouts. But a survey of protocol implementations
> >>     shows that all drivers issue Sync messages when preparing, and adding
> >>     timeout rearming to both is fairly expensive for the common parse /
> >>     bind / execute sequence.
> >>    
> >>     Author: Tatsuo Ishii, editorialized by Andres Freund
> >>     Reviewed-By: Takayuki Tsunakawa, Andres Freund
> >>     Discussion: https://postgr.es/m/20170222.115044.1665674502985097185.t-ishii@...
> >
> > That seemed too detailed for the release notes.  Is that wrong?
>
> This commit gives user-visible changes to the statment timeout
> behavior. So I think this should be added to the release notes.

OK, makes sense. Here is what I added:

        2017-09-18 [f8e5f156b] Rearm statement_timeout after each executed query.

        In the <link linkend="protocol-query-concepts">Extended Query
        Protocol</link>, have <varname>statement_timeout</varname> apply
        to each <literal>Execute</literal> message, not to all commands
        before <literal>Sync</literal> (Tatsuo Ishii)

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

123456 ... 13