Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iEqOg-000417-7P for pgsql-docs@arkaria.postgresql.org; Mon, 30 Sep 2019 07:47:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iEqOe-00066r-Sd for pgsql-docs@arkaria.postgresql.org; Mon, 30 Sep 2019 07:47:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iEqOe-00066c-IZ for pgsql-docs@lists.postgresql.org; Mon, 30 Sep 2019 07:47:04 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iEqOb-0001Iu-L1 for pgsql-docs@lists.postgresql.org; Mon, 30 Sep 2019 07:47:04 +0000 Received: by mail-pl1-x62f.google.com with SMTP id w8so3118761plq.5 for ; Mon, 30 Sep 2019 00:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=Wuk+Wvs3ni9CaDrVNWVJOSxErGDvNzWZReNbW7YNhR8=; b=MW4FjZZex4ekcs0S0pPJGwfAKycfC5019D1/ZUNtRAlbmor8/V1MalYf5SW76BE/5r /7JRe6x/eOPXm5GeH52oko3xcDev1GPmeVsPPdmgo5tEf/DGwdBZKve+srhKaVUksMaQ L1mQThxGzUiEcO4tYwQ8uVIxWmipi4kKQFYFi+PCIGHL258p/i4EVKbogto3umiO4Uu0 cSSjWnwlNpB/9Tg/wfU33pOuA0L68o7SWZrX+3Xh2TiMjppLJPOE/mcBfO0oCids4ct1 tSMuAtiBtPVoiSllBDDQp5w5csHGIpBEGBLmN7xLXH8W//TOpCDoo5Mp5zu7k3babF3i 1VBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=Wuk+Wvs3ni9CaDrVNWVJOSxErGDvNzWZReNbW7YNhR8=; b=flTLt+CXP3auZwz4ytvL7+6slCjB3lX1ChyoE3R+g8xaZNdmfBI2H7URvypIpCV2H/ pmFVx8x8sp7ICUZ0COINs3k7gKPAvRoyAyuht9OVVtF/AhxU5v55dQ96LTryqgqs3ZMO u3XgUQkB4XYY3rLo5LfNdJfEGUKcAwXrC0DryTvHVCcMoOZw0G38WAnlFRY12960s2/r NB829X+VPe4cFqmGu95QxrIzUrtiIZLje32ZiLmSo3tvOW1KbjESBqSuyt5dCNXNi42R MxC4tN3GgGIpS440jeoB2EkN0wj5W4K5BOjcIcpo0+xIguQF6DUBt8uRqqfFvV6j6FtN FLow== X-Gm-Message-State: APjAAAUQpifPN+nUosN2hB1jE+9NyQahYcGnaDjidNFy/Cqz6GUQvRJ2 JxhURqSxnDPCrvdE4Il6mLw= X-Google-Smtp-Source: APXvYqzbFbES7pOizBvcIFYnCzOgQD+acL/RtHXUfJ0QjPdW3bTUySkaCKFYoPE/ghPqWgBKltIFdQ== X-Received: by 2002:a17:902:7796:: with SMTP id o22mr19063555pll.222.1569829617940; Mon, 30 Sep 2019 00:46:57 -0700 (PDT) Received: from ?IPv6:2404:7a80:a8e0:9800:8db0:c11e:4bda:5d8? ([2404:7a80:a8e0:9800:8db0:c11e:4bda:5d8]) by smtp.gmail.com with ESMTPSA id r30sm12953684pfl.42.2019.09.30.00.46.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Sep 2019 00:46:57 -0700 (PDT) Message-ID: <5d91b2f1.1c69fb81.bf75c.2036@mx.google.com> MIME-Version: 1.0 To: Tom Lane Cc: "pgsql-docs@lists.postgresql.org" From: Aramaki Zyake Subject: RE: Required locks for ANALYZE Date: Mon, 30 Sep 2019 16:46:56 +0900 Importance: normal X-Priority: 3 In-Reply-To: <6129.1566310344@sss.pgh.pa.us> References: <156628723253.1296.7377373462603881976@wrigleys.postgresql.org> <6129.1566310344@sss.pgh.pa.us> Content-Type: multipart/alternative; boundary="_4CB1891D-EE22-4531-BD28-12D7AD93E932_" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --_4CB1891D-EE22-4531-BD28-12D7AD93E932_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi, I=E2=80=99m terribly sorry for the delay of response. >This does not really seem like an improvement. The second formulation is >pedantically correct, but also unintelligible. > > Maybe we could make it say "run in parallel with non-DDL activity" ? I completely agree with you, therefore, I amended it as follows. ---- ANALYZE requires only a read lock on the target table, so it can run in parallel with non-DDL activity on the table. ---- Would it be possible to proceed further? Best regards From: Tom Lane Sent: Tuesday, August 20, 2019 11:12 PM To: zyake.mk4@gmail.com Cc: pgsql-docs@lists.postgresql.org Subject: Re: Required locks for ANALYZE PG Doc comments form writes: > Therefore, in my opinion, the below paragraph should be amended as below. > * Before > ----- > ANALYZE requires only a read lock on the target table, so it can run in > parallel with other activity on the table. > ----- > * After > ----- > ANALYZE requires only a SHARE UPDATE EXCLUSIVE lock on the target table, = so > it can run in parallel with queries requiring ACCESS SHARE/ROW SHARE/ROW > EXCLUSIVE locks such as SELECT, UPDATE, DELETE, INSERT on the table. > ----- This does not really seem like an improvement. The second formulation is pedantically correct, but also unintelligible. Maybe we could make it say "run in parallel with non-DDL activity" ? regards, tom lane --_4CB1891D-EE22-4531-BD28-12D7AD93E932_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi,

I=E2=80= =99m terribly sorry for the delay of response.

 

>This does not really seem li= ke an improvement.=C2=A0 The second formulation is

= >pedantically correct, but also unintelligible.

> 

> Maybe we could mak= e it say "run in parallel with non-DDL activity" ?

=

 

I completely= agree with you, therefore, I amended it as follows.

----

ANALYZE requires only a read lock= on the target table, so it can run in

p= arallel with non-DDL activity on the table.

----

 

Would it be possible to proceed further?


Best regards

 

 

From: Tom Lane
Sent: Tuesday, August 20, = 2019 11:12 PM
To: zyake.mk= 4@gmail.com
Cc: pgsql-docs@lists.postgresql.org
Subject: Re: Required l= ocks for ANALYZE

 

PG Doc comments form <noreply@postgresql.org> writes:

> Therefore, in my opinion, the below paragraph s= hould be amended as below.

 

> * Before

> -----

> ANALYZE requires only a read lock on the target table,= so it can run in

> parallel with other activity= on the table.

> -----

<= o:p> 

> * After

> -----

> ANALYZE requires only a SHARE UP= DATE EXCLUSIVE lock on the target table, so

> it= can run in parallel with queries requiring ACCESS SHARE/ROW SHARE/ROW

<= p class=3DMsoNormal>> EXCLUSIVE locks such as SELECT, UPDATE, DELETE, IN= SERT on the table.

> -----

 

This does not really seem like= an improvement.=C2=A0 The second formulation is

pe= dantically correct, but also unintelligible.

&= nbsp;

Maybe we could make it say "run in= parallel with non-DDL activity" ?

 =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 regards, tom lane

 

= --_4CB1891D-EE22-4531-BD28-12D7AD93E932_--