From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Andy Fan <zhihuifan1213(at)163(dot)com>, Nikita Malakhov <hukutoc(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: Considering fractional paths in Append node |
Date: | 2024-10-17 03:57:50 |
Message-ID: | feca5531-753e-4ded-b9c1-b3334812aacf@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/17/24 07:05, Andy Fan wrote:
> Nikita Malakhov <hukutoc(at)gmail(dot)com> writes:
>
> Helll Nikita,
>
>> Hi hackers!
>>
>> Sorry, I've forgot to attach the patch itself. Please check it out.
>
> Could you check if [1] is related to this subject? I think the hard part
> would be which tuple_fraction to use during adding
> add_paths_to_append_rel since root->tuple_fraction is on subquery level,
> while the add_paths_to_append_rel is only on RelOptInfo level.
>
> [1]
> https://www.postgresql.org/message-id/CAApHDvry0nSV62kAOH3iccvfPhGPLN0Q97%2B%3Db1RsDPXDz3%3DCiQ%40mail.gmail.com
Yes, this thread is connected to the code Nikita has proposed.
It is almost related to partitioned cases, of course.
I'm not sure about partitionwise joins - it looks overcomplicated for
the moment. We just see cases when SeqScan is preferred to IndexScan.
One logical way is to add into the Append node an alternative fractional
path and, if at the top level some Limit, IncrementalSort or another
fractional-friendly node will request only a small part of the data, the
optimiser will have the option to choose the fractional path.
--
regards, Andrei Lepikhov
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2024-10-17 03:58:48 | Re: Set query_id for query contained in utility statement |
Previous Message | Bruce Momjian | 2024-10-17 02:45:41 | Re: wrong comment in libpq.h |