Re: JIT performance bug/regression & JIT EXPLAIN
Maciek Sakrejda <m.sakrejda@gmail.com>
From: Maciek Sakrejda <m.sakrejda@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-11-16T01:04:52Z
Lists: pgsql-hackers
On Fri, Nov 15, 2019 at 5:49 AM Robert Haas <robertmhaas@gmail.com> wrote: > Personally, I don't care very much about backward-compatibility, or > about how hard it is for tools to parse. I want it to be possible, but > if it takes a little extra effort, so be it. I think these are two separate issues. I agree on backward-compatibility (especially if we can embed a server version in structured EXPLAIN output to make it easier for tools to track format differences), but not caring how hard it is for tools to parse? What's the point of structured formats, then? > My main concern is having > the text output look good to human beings, because that is the primary > format and they are the primary consumers. Structured output is also for human beings, albeit indirectly. That text is the primary format may be more of a reflection of the difficulty of building and integrating EXPLAIN tools than its inherent superiority (that said, I'll concede it's a concise and elegant format for what it does). What if psql supported an EXPLAINER like it does EDITOR? For what it's worth, after thinking about this a bit, I'd like to see structured EXPLAIN evolve into a more consistent format, even if it means breaking changes (and I do think a version specifier at the root of the plan would make this easier).
Commits
-
jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
- 2ce9bca36458 12.0 landed
- 51ad5b9bd3e3 11.6 landed
- ac88807f9b22 13.0 landed
-
Fix determination when slot types for upper executor nodes are fixed.
- 6cf74f1bbd65 12.0 landed
- 97e971ee05d5 13.0 landed