Re: JIT performance bug/regression & JIT EXPLAIN

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: JIT performance bug/regression & JIT EXPLAIN
Дата
Msg-id CA+TgmoYXTchjLctjovKdWuqx+AhN0=D8qdRZT0YDc6s2rwrFfw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: JIT performance bug/regression & JIT EXPLAIN  (Andres Freund <andres@anarazel.de>)
Ответы Re: JIT performance bug/regression & JIT EXPLAIN
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: AtEOXact_Snapshot timing
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Creating foreign key on partitioned table is too slow