Re: JIT performance bug/regression & JIT EXPLAIN - Mailing list pgsql-hackers

From Maciek Sakrejda
Subject Re: JIT performance bug/regression & JIT EXPLAIN
Date
Msg-id CAOtHd0Ar_L33QKWqkjmAw=J90KO7jrrbzAZ6YEpYxDs4+Oy8bQ@mail.gmail.com
Whole thread Raw
In response to JIT performance bug/regression & JIT EXPLAIN  (Andres Freund <andres@anarazel.de>)
Responses Re: JIT performance bug/regression & JIT EXPLAIN
List pgsql-hackers
>But that's pretty crappy, because it means that the 'shape' of the output depends on the jit_details option.

Yeah, that would be hard to work with. What about adding it as a sibling group?

"Filter": "(lineitem.l_shipdate <= '1998-09-18 00:00:00'::timestamp
without time zone)",
"Filter JIT": {
  "Expr": "evalexpr_0_2",
  "Deform Scan": "deform_0_3",
  "Deform Outer": null,
  "Deform Inner": null
}

Also not that pretty, but at least it's easier to work with (I also
changed the dashes to spaces since that's what the rest of EXPLAIN is
doing as a matter of style).

>But the compat break due to that change is not small- perhaps we could instead mark that in another way?

We could add a "Projects" boolean key instead? Of course that's more
awkward in text mode. Maybe compat break is less of an issue in text
mode and we can treat this differently?

>I'm not sure that 'TRANS' is the best placeholder for the transition value here. Maybe $TRANS would be clearer?

+1, I think the `$` makes it clearer that this is not a literal expression.

>For HashJoin/Hash I've added 'Outer Hash Key' and 'Hash Key' for each key, but only in verbose mode.

That reads pretty well to me. What does the structured output look like?



pgsql-hackers by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence
Next
From: Robert Haas
Date:
Subject: Re: JIT performance bug/regression & JIT EXPLAIN