Re: Missed compiler optimization issue in function select_rtable_names_for_explain

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.

In response to

Responses

Browse pgsql-general by date

  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