On 25/08/2020 20:48, David Rowley wrote:
On Tue, 25 Aug 2020 at 08:26, Andres Freund <and...@anarazel.de> wrote:
While I'm against introducing a separate node for the caching, I'm *not*
against displaying a different node type when caching is
present. E.g. it'd be perfectly reasonable from my POV to have a 'Cached
Nested Loop' join and a plain 'Nested Loop' node in the above node. I'd
probably still want to display the 'Cache Key' similar to your example,
but I don't see how it'd be better to display it with one more
intermediary node.
...Well, this is difficult... For the record, in case anyone missed
it, I'm pretty set on being against doing any node overloading for
this. I think it's a pretty horrid modularity violation regardless of
what text appears in EXPLAIN. I think if we merge these nodes then we
may as well go further and merge in other simple nodes like LIMIT.
Then after a few iterations of that, we end up with with a single node
in EXPLAIN that nobody can figure out what it does. "Here Be Dragons",
as Tom said. That might seem like a bit of an exaggeration, but it is
important to understand that this would start us down that path, and
the more steps you take down that path, the harder it is to return
from it.
[...]
I understand that you've voiced your feelings about this, but what I
want to know is, how strongly do you feel about overloading the node?
Will you stand in my way if I want to push ahead with the separate
node? Will anyone else?
David
From my own experience, and thinking about issues like this, I my
thinking keeping them separate adds robustness wrt change. Presumably
common code can be extracted out, to avoid excessive code duplication?
-- Gavin
