Re: Missed compiler optimization issue in function select_rtable_names_for_explain

Alvaro Herrera writes: > I think if we want to improve how this code is seen by the compiler by > modifying it, we should just remove the NULL/NIL assignments. It's a > pretty arbitrary (and rather small) subset of fields being initialized, > fields which very obviously have been zeroed by memset

Re: Missed compiler optimization issue in function select_rtable_names_for_explain

> On 22 May 2024, at 18:53, Tom Lane wrote: > > Daniel Gustafsson writes: >> They are known to be zero, but that's not entirely equivalent though is it? >> NIL is defined as ((List *) NULL) and NULL is typically defined as ((void *) >> 0), so sizeof(0) would be the size of an int and sizeof(NULL

Re: Missed compiler optimization issue in function select_rtable_names_for_explain

> On 22 May 2024, at 13:00, Alvaro Herrera wrote: > I think if we want to improve how this code is seen by the compiler by > modifying it, we should just remove the NULL/NIL assignments. *If* the optimization is measurable, IMHO. > It's a > pretty arbitrary (and rather small) subset of fields b

Re: Missed compiler optimization issue in function select_rtable_names_for_explain

On 2024-May-22, XChy wrote: > Hi everyone, > > I'm a compiler developer working on detecting missed optimization in > real-world applications. Recently, we found that LLVM missed a dead store > elimination optimization in the PostgreSQL code >

Re: Missed compiler optimization issue in function select_rtable_names_for_explain

Daniel Gustafsson writes: > They are known to be zero, but that's not entirely equivalent though is it? > NIL is defined as ((List *) NULL) and NULL is typically defined as ((void *) > 0), so sizeof(0) would be the size of an int and sizeof(NULL) would be the > size > of a void pointer. There ar

Re: Missed compiler optimization issue in function select_rtable_names_for_explain

在 2024/5/22 18:55, Daniel Gustafsson 写道: 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. They

Re: Missed compiler optimization issue in function select_rtable_names_for_explain

> On 22 May 2024, at 12:12, XChy wrote: > >> 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? > For the first q

Re: Missed compiler optimization issue in function select_rtable_names_for_explain

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 mems

Re: Missed compiler optimization issue in function select_rtable_names_for_explain

> On 22 May 2024, at 11:27, XChy wrote: > > Hi everyone, > I'm a compiler developer working on detecting missed optimization in > real-world applications. Recently, we found that LLVM missed a dead store > elimination optimization in the PostgreSQL code > (https://github.com/postgres/postgres/

Missed compiler optimization issue in function select_rtable_names_for_explain

Hi everyone, I'm a compiler developer working on detecting missed optimization in real-world applications. Recently, we found that LLVM missed a dead store elimination optimization in the PostgreSQL code

Re: optimization issue

Hi, Could you suggest me how should I teduce the heap blocks to optimise the query ? Regards. On Thursday, July 8, 2021, Atul Kumar wrote: > Hi, > > I have one query like below : > > > SELECT > m.iMemberId "memberId", >

Re: optimization issue

Hello Ken, On Fri, 2021-07-09 at 13:27 -0500, Kenneth Marshall wrote: > On Fri, Jul 09, 2021 at 01:16:16PM +1000, rob stone wrote: > > Hello, > > > > I am curious. > > > > NVL, DECODE and SELECT FROM dual are Oracle methods and these > > appear in > > your code. > > > > How did you make these w

Re: optimization issue

On Fri, Jul 09, 2021 at 01:16:16PM +1000, rob stone wrote: > Hello, > > I am curious. > > NVL, DECODE and SELECT FROM dual are Oracle methods and these appear in > your code. > > How did you make these work in Postgres?  > > Cheers, > Rob Hi Rob, At a guess, they are using the Orafce PostgreS

Re: optimization issue

Hello, I am curious. NVL, DECODE and SELECT FROM dual are Oracle methods and these appear in your code. How did you make these work in Postgres?  Cheers, Rob

Re: optimization issue

Hi Lewis, I am new to postgres. Could you tell me how should I put the result on an analyzed temp table at least ? Please suggest. Regards. On Thursday, July 8, 2021, Michael Lewis wrote: > ((current_setting('env.groupid'::text))::integer)::numeric > > If you pass this value in directl

Re: optimization issue

((current_setting('env.groupid'::text))::integer)::numeric If you pass this value in directly as part of the query string, how does it perform? It seems like calling the function to get this value may be creating a planning problem with the value unknown at plan time. If you were able to put the r

optimization issue

Hi, I have one query like below : SELECT m.iMemberId "memberId", m.cFirstName "firstName", m.cLastName "lastName", m.cFirstName || ' '