public inbox for [email protected]
help / color / mirror / Atom feedFrom: XChy <[email protected]>
To: Daniel Gustafsson <[email protected]>
Cc: [email protected]
Subject: Re: Missed compiler optimization issue in function select_rtable_names_for_explain
Date: Wed, 22 May 2024 18:12:57 +0800
Message-ID: <OS0P286MB01632009BF9AA52386BA9E4D82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <[email protected]>
References: <OS0P286MB016392E0B2017DDB6709A11C82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
<[email protected]>
> 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.
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Missed compiler optimization issue in function select_rtable_names_for_explain
In-Reply-To: <OS0P286MB01632009BF9AA52386BA9E4D82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox