From: | XChy <xxs_chy(at)outlook(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Missed compiler optimization issue in function select_rtable_names_for_explain |
Date: | 2024-05-22 10:12:57 |
Message-ID: | OS0P286MB01632009BF9AA52386BA9E4D82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | o1bigtenor | 2024-05-22 10:53:02 | Re: Regarding use case of epoch to generate nanoseconds precision |
Previous Message | Daniel Gustafsson | 2024-05-22 09:51:00 | Re: Missed compiler optimization issue in function select_rtable_names_for_explain |