From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Date: | 2020-11-02 07:43:54 |
Message-ID: | CAApHDvodw7UA8m_igHWYejBjcsXZ8RAqi7-oVYTwbhRJtHaZVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 20 Oct 2020 at 22:30, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> So far benchmarking shows there's still a regression from the v8
> version of the patch. This is using count(*). An earlier test [1] did
> show speedups when we needed to deform tuples returned by the nested
> loop node. I've not yet repeated that test again. I was disappointed
> to see v9 slower than v8 after having spent about 3 days rewriting the
> patch
I did some further tests this time with some tuple deforming. Again,
it does seem that v9 is slower than v8.
Graphs attached
Looking at profiles, I don't really see any obvious reason as to why
this is. I'm very much inclined to just pursue the v8 patch (separate
Result Cache node) and just drop the v9 idea altogether.
David
Attachment | Content-Type | Size |
---|---|---|
image/png | 56.2 KB | |
image/png | 69.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2020-11-02 07:50:58 | Re: Parallel copy |
Previous Message | Amit Langote | 2020-11-02 07:40:53 | Re: making update/delete of inheritance trees scale better |