Horton

Re: Considering fractional paths in Append node

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Andy Fan <zhihuifan1213@163.com>, Nikita Malakhov <hukutoc@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, David Rowley <dgrowleyml@gmail.com>
Date: 2024-10-17T03:57:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Teach Append to consider tuple_fraction when accumulating subpaths.

On 10/17/24 07:05, Andy Fan wrote:
> Nikita Malakhov <hukutoc@gmail.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