From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Date: | 2020-08-19 21:59:38 |
Message-ID: | CAApHDvoTTT9htwPzZ9ksxqtyQSKG1JWdhz9A0xHw-NnhknhvUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 19 Aug 2020 at 16:23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > I don't object to making the change. I just object to making it only
> > to put it back again later when someone else speaks up that they'd
> > prefer to keep nodes modular and not overload them in obscure ways.
>
> > So other input is welcome. Is it too weird to overload SubPlan and
> > Nested Loop this way? Or okay to do that if it squeezes out a dozen
> > or so nanoseconds per tuple?
>
> If you need somebody to blame it on, blame it on me - but I agree
> that that is an absolutely horrid abuse of NestLoop. We might as
> well reduce explain.c to a one-liner that prints "Here Be Dragons",
> because no one will understand what this display is telling them.
Thanks for chiming in. I'm relieved it's not me vs everyone else anymore.
> I'm also quite skeptical that adding overhead to nodeNestloop.c
> to support this would actually be a net win once you account for
> what happens in plans where the caching is of no value.
Agreed.
David
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-08-19 22:04:10 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Previous Message | Alvaro Herrera | 2020-08-19 21:13:12 | "ccold" left by reindex concurrently are droppable? |