Re: JIT performance bug/regression & JIT EXPLAIN

Поиск
Список
Период
Сортировка
От Maciek Sakrejda
Тема Re: JIT performance bug/regression & JIT EXPLAIN
Дата
Msg-id CAOtHd0BVxNF978MJS3_2GdGJVM4BPpyK5RHz=jve3RZnnnhZyQ@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 5:02 PM Andres Freund <andres@anarazel.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.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Missing dependency tracking for TableFunc nodes
Следующее
От: Nikita Glukhov
Дата:
Сообщение: Re: SQL/JSON: JSON_TABLE