Content-Type: multipart/alternative;
 boundary="------------4ZgneKJ9jN46T0e45OBMhYUz"
Message-ID:
 <OS0P286MB01632009BF9AA52386BA9E4D82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
Date: Wed, 22 May 2024 18:12:57 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: Missed compiler optimization issue in function
 select_rtable_names_for_explain
To: Daniel Gustafsson <daniel@yesql.se>
References: <OS0P286MB016392E0B2017DDB6709A11C82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
 <05C4ADF5-5E8C-49EC-8E0A-804BB946F1C7@yesql.se>
Content-Language: en-US
Cc: pgsql-general@postgresql.org
From: XChy <xxs_chy@outlook.com>
In-Reply-To: <05C4ADF5-5E8C-49EC-8E0A-804BB946F1C7@yesql.se>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS0P286MB0163:EE_|OS3P286MB1711:EE_
X-MS-Office365-Filtering-Correlation-Id: 600a1070-8dfc-46f8-f668-08dc7a47c38c
X-Microsoft-Antispam: BCL:0;ARA:14566002|461199019|440099019|3412199016;
X-Microsoft-Antispam-Message-Info:
	pnNFeQzevNxtINy5xl9PJifzhVGEsd2yQcKvrjPmpusJwbST/T+LQfB2IbWECEdxxV2Imb3opfBwoWZQFi3Z/vAqCd+UN92iY8duOEPqjlZcrOw7y2KegrzARXtQvq2aTEHEribdrPsvSAyB9kZ9WHEKsrc3fyYkg6ew8Fk5nLkf/vLGdxf0nHZk8Q0uBaVqJH43GdN7PzSXAWcwbFHK4SqSmphU7pTuKE7+EtEi0LbUdfaR3VokVrni9dMeGfDRFt6fayww4+ib0gRNEJk3gDAUzwPd8lsTkVNsxVgyMgVtZLzEoqXSu/VBEbYbl5NQC+8yAGW013npZoXDgad79apxFsNJNtZbc8vxbFPJ20h+s+AaZ5LI7Q2sCvEhjq9vquMN3xzNV7w+T09DMWwz2g/EDVrTzMM4q4YSp5dvasoSB4zIVOibZjlxUYW+k6y6+tQhLmxlDWDrb2pCcDALuzLDhAhPXTtAuVgsbU55Jqdf+0rigmGKxhw2BjyFZN7vSbj6SRsYFc+SQYRQlbtEGoOHSu5xV8V4+oA8pgSlza7M+od+4hPrI7Ney8hFW7E0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?Sk9RaDVkR2xYcU05dk1CWktYWWMwejVqUHY2ekE3Nm5Ra2xteUVmMWE1OHRE?=
 =?utf-8?B?MXFxQ091VDJaSHI3UW5ZTWZqMUNDZEd0a2FIWjZCampSYjRCUXphL2dLWUV6?=
 =?utf-8?B?a0cyV2xYSjFnK05pdW1adnJ4dkRZVHJsZE0wMDJMQXc0SkUxMlI0RStrTjZr?=
 =?utf-8?B?Sm5NQlZRMFVGSU1maUhhNmVWNkpSRjJ6b2Z1MUxIMWg0emxmaEdvd2wzcVZH?=
 =?utf-8?B?bWxRVndRSmFOck5ReGdKRWU4Ty9BeGFSVnB0aEJndTR5YVlHQmwwbnltMmVC?=
 =?utf-8?B?OWovckc5TFZtcDlKTDJJKzNMakRIenJQR3JZclk4V3NsVDBmL3NyUHFNTkRU?=
 =?utf-8?B?dnlBcDY4djNjR0VDNGhRUWlEZk5jb0svMlp4ZXYyWFJ5N3gxQWhUTmFDNkt1?=
 =?utf-8?B?a2dwRDhKSmJ3ZkM2RHlSSGVlbnpOV0orSXd1MjNkd3FoK2tSZzFid0VnK0c2?=
 =?utf-8?B?Z1ZGZ1JVWC8zUnpuNDNJQ24zWW5rU2ViS245WTBJbHZPL21xY2lPRURtdnpN?=
 =?utf-8?B?NjJqZ1JPTlRCU3ZVODF1WGdmZ0dpRmxycGErN3U4bTQvZGFNbVVEcWZ6YmEy?=
 =?utf-8?B?VjQvWDhKMXE5amdkQzFGdHNORVR0dTdzbzFvd2RPN1g0bVJTamV5WG5BTkIz?=
 =?utf-8?B?SG9nb3pyTERJZkNmR2xDY2xjMUQyZ2w5UmdVci82SSsyalA0dTRXUHNLTDB2?=
 =?utf-8?B?Ulh3VEd3SU9WSkdVY2UwTlY2Rkpnb3RqZGxmaGdnbFc5RHptcjhGcEQwU0Zj?=
 =?utf-8?B?Qk14V29uU1lWM3lmaENQWWdMVmw1Y2xxbVh3SGJlaUx0bFUvR2VQWTg4dnZY?=
 =?utf-8?B?NVkrRTdwSDNVcFQvYkhhT1RRSkRuUHMrUS9UeURVT3lqTm9QamhjM3JVVFFY?=
 =?utf-8?B?MVNHSE9CRmtkWUtMTnVnYnM4SEJZYUlLWENLZnhPalBTQ09qS2x1bXVWaXFj?=
 =?utf-8?B?Z0xWRFc1bTNKNlFJbUovSjdwbkRPdUYyTW81VE8yWXRLRTNzYUZvUHJIVGRP?=
 =?utf-8?B?Y1I3cC81SmFnd3NsZjltazVPc0N5eUNMRHl4aTZVaG5nWjZkVGdkTXorcUlB?=
 =?utf-8?B?bEY4aE85SWJmeWRIWnZzbjIrd29WOVdQRFMwNTI3eW0xdk8xTlRmNm9zeHZK?=
 =?utf-8?B?Y3k1K2pwbWVuTFV5RUpFc1dtN0ZpYWhKejNlemM1emZ2aHRmL205emQ1QU5t?=
 =?utf-8?B?UVRZQ0NiNEJ3MFRsVHMrT2Z1VzZFUFNzdnNIU3BIWmUybGJWNFlCaFdCU1Ra?=
 =?utf-8?B?UzVOc0FadmVOUE9TeEdnOGxNQmJYcUJGQVRvNFg4OU0wTUExWTMvMUtMYlJx?=
 =?utf-8?B?eEYvbkxrK1FlVWVwbEtRVXVkUVhIM0xVK2EzM2RwY3puU2FadFJPLzM4dTVy?=
 =?utf-8?B?SHBRcWlMVGJDY1lHMHhUR3Q4c0tVZmhoVWJHUUdnQVpQeTVnUHl6NytFa0Rp?=
 =?utf-8?B?VStTNk1jOUdFSlZ0OUVMSE9FQzJ4b01JK3pmMG10RFBWMVR4ZUtoc0Vxd3BV?=
 =?utf-8?B?YkNjRERDZFNITWFEcU5rdnhhdHhvQ0Y1ZS9YakdyeUNOeUtzaGl2R1VzdEg2?=
 =?utf-8?B?R1pCcVFaYkRiUTNrYkVRQkVYYXdCMEhET0s4Vlcxa0V1aWJWc2c4dFNXVEdx?=
 =?utf-8?Q?9qxfuDcjdjWOIGAUktQIGA1pImY0JCid3qu+uOOYLFJY=3D?=
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 600a1070-8dfc-46f8-f668-08dc7a47c38c
X-MS-Exchange-CrossTenant-AuthSource: OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2024 10:13:02.4079
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS3P286MB1711
List-Id: <pgsql-general.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-general@lists.postgresql.org>
List-Owner: <mailto:pgsql-general-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-general>
Archived-At: <https://www.postgresql.org/message-id/OS0P286MB01632009BF9AA52386BA9E4D82EB2%40OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
Precedence: bulk

--------------4ZgneKJ9jN46T0e45OBMhYUz
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

> How is the memset in select_rtable_names_for_explain a dead-store? 
> Even memset
> calls could be optimized away from the EXPLAIN codepath I have a feeling it
> would have to be many in a tight loop for it to be measurable even?
>
> --
> Daniel Gustafsson

For the first question, I don't mean that the memset is the dead store. 
I mean that the stores with value "0" after the memset are dead:

```

     dpns.subplans = NIL;
     dpns.ctes = NIL;
     dpns.appendrels = NULL;
```
since the memset has written zeroes to the object "dpns", and these 
members are known to be zero.

For the second question, you are right, I don't really profile it or 
measure the performance impact for it. I just think it's worthwhile to 
improve codegen quality without affecting readability, as adopting 
performance tips from some static analyzer.

Best regards, Hongyu.

--------------4ZgneKJ9jN46T0e45OBMhYUz
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <blockquote type="cite" cite="mid:05C4ADF5-5E8C-49EC-8E0A-804BB946F1C7@yesql.se"><span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">How is the memset in select_rtable_names_for_explain a dead-store?  Even memset</span>
      <pre class="moz-quote-pre" wrap="">calls could be optimized away from the EXPLAIN codepath I have a feeling it
would have to be many in a tight loop for it to be measurable even?

--
Daniel Gustafsson
</pre>
    </blockquote>
    <p>For the first question, I don't mean that <span style="white-space: pre-wrap">the memset is the dead store. I mean that the stores with value &quot;0&quot; after the memset are dead:</span></p>
    <p><span style="white-space: pre-wrap">```
<span style="white-space: normal"></span></span></p>
    <div class="moz-cite-prefix">&nbsp;&nbsp;&nbsp; dpns.subplans = NIL;<br>
      &nbsp;&nbsp; &nbsp;dpns.ctes = NIL;<br>
      &nbsp;&nbsp; &nbsp;dpns.appendrels = NULL;</div>
    <div class="moz-cite-prefix">```<br>
    </div>
    <div class="moz-cite-prefix">since the memset has written zeroes to
      the object &quot;dpns&quot;, and these members are known to be zero.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">For the second question, you are right,
      I don't really profile it or measure the performance impact for
      it. I just think it's worthwhile to improve codegen quality
      without affecting readability, as adopting performance tips from
      some static analyzer.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Best regards, Hongyu.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
  </body>
</html>

--------------4ZgneKJ9jN46T0e45OBMhYUz--