From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Antonin Houska <ah(at)cybertec(dot)at> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Problem about postponing gathering partial paths for topmost scan/join rel |
Date: | 2022-07-18 07:13:05 |
Message-ID: | CAMbWs4-HnzGqZkhGP8+QCWaSLq950w-AQsZ4t6nUta-iNAB+fA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 15, 2022 at 5:00 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> On Fri, Jul 15, 2022 at 4:03 PM Richard Guo <guofenglinux(at)gmail(dot)com>
> wrote:
>
>> On Thu, Jul 14, 2022 at 10:02 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:
>>
>>> I'd prefer a test that demonstrates that the Gather node at the top of
>>> the
>>> "subproblem plan" is useful purely from the *cost* perspective, rather
>>> than
>>> due to executor limitation.
>>
>>
>> This patch provides an additional path (Gather atop of subproblem) which
>> was not available before. But your concern makes sense that we need to
>> show this new path is valuable from competing on cost with other paths.
>>
>> How about we change to Nested Loop at the topmost? Something like:
>>
>
> Maybe a better example is that we use a small table 'c' to avoid the
> Gather node above scanning 'c', so that the path of parallel nestloop is
> possible to be generated.
>
Update the patch with the new test case.
Thanks
Richard
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Gather-partial-paths-for-subproblem-s-topmost-sca.patch | application/octet-stream | 2.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Kalcher | 2022-07-18 07:47:30 | Re: Proposal to introduce a shuffle function to intarray extension |
Previous Message | Martin Kalcher | 2022-07-18 07:12:50 | Re: Proposal to introduce a shuffle function to intarray extension |