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

From Robert Haas
Subject Re: JIT performance bug/regression & JIT EXPLAIN
Date
Msg-id CA+TgmoYXTchjLctjovKdWuqx+AhN0=D8qdRZT0YDc6s2rwrFfw@mail.gmail.com
Whole thread Raw
In response to Re: JIT performance bug/regression & JIT EXPLAIN  (Andres Freund <andres@anarazel.de>)
Responses Re: JIT performance bug/regression & JIT EXPLAIN  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Oct 28, 2019 at 7:21 PM Andres Freund <andres@anarazel.de> wrote:
> Because that's the normal way to represent something non-existing for
> formats like json? There's a lot of information we show always for !text
> format, even if not really applicable to the context (e.g. Triggers for
> select statements). I think there's an argument to made to deviate in
> this case, but I don't think it's obvious.

I've consistently been of the view that anyone who thinks that the
FORMAT option should affect what information gets displayed doesn't
understand the meaning of the word "format." And I still feel that
way.

I also think that conditionally renaming "Output" to "Project" is a
super-bad idea. The idea of a format like this is that the "keys" stay
constant and the values change. If you need to tell people more, you
add more keys.

I also think that making the Filter field a group conditionally is a
bad idea, for similar reasons. But making it always be a group doesn't
necessarily seem like a bad idea. I think, though, that you could
handle this in other ways, like by suffixing existing keys.  e.g. if
you've got Index-Qual and Filter, just do Index-Qual-JIT and
Filter-JIT and call it good.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: AtEOXact_Snapshot timing
Next
From: Tom Lane
Date:
Subject: Re: Creating foreign key on partitioned table is too slow