Re: JIT performance bug/regression & JIT EXPLAIN

Maciek Sakrejda <m.sakrejda@gmail.com>

From: Maciek Sakrejda <m.sakrejda@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Date: 2019-10-28T18:27:02Z
Lists: 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?



Commits

  1. jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.

  2. Fix determination when slot types for upper executor nodes are fixed.