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-11-12 21:42:10
Message-ID: CAOtHd0BVxNF978MJS3_2GdGJVM4BPpyK5RHz=jve3RZnnnhZyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 28, 2019 at 5:02 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> What I dislike about that is that it basically again is introducing

"again"? Am I missing some history here? I'd love to read up on this
if there are mistakes to learn from.

> something that requires either pattern matching on key names (i.e. a key
> of '(.*) JIT' is one that has information about JIT, and the associated
> expresssion is in key $1), or knowing all the potential keys an
> expression could be in.

That still seems less awkward than having to handle a Filter field
that's either scalar or a group. Most current EXPLAIN options just add
additional fields to the structured plan instead of modifying it, no?
If that output is better enough, though, maybe we should just always
make Filter a group and go with the breaking change? If tooling
authors need to treat this case specially anyway, might as well evolve
the format.

> Another alternative would be to just remove the 'Output' line when a
> node doesn't project - it can't really carry meaning in those cases
> anyway?

¯\_(ツ)_/¯

For what it's worth, I certainly wouldn't miss it.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Glukhov 2019-11-12 21:47:59 Re: SQL/JSON: JSON_TABLE
Previous Message legrand legrand 2019-11-12 21:41:15 Re: BUG #16109: Postgres planning time is high across version - 10.6 vs 10.10