Re: JIT performance bug/regression & JIT EXPLAIN

From: Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: JIT performance bug/regression & JIT EXPLAIN
Date: 2019-10-28 18:27:02
Message-ID: CAOtHd0Ar_L33QKWqkjmAw=J90KO7jrrbzAZ6YEpYxDs4+Oy8bQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-10-28 19:05:01 Re: JIT performance bug/regression & JIT EXPLAIN
Previous Message Anastasia Lubennikova 2019-10-28 18:11:12 Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence