| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Nikita Malakhov <hukutoc(at)gmail(dot)com>, Andy Fan <zhihuifan1213(at)163(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Subject: | Re: Considering fractional paths in Append node |
| Date: | 2024-12-06 06:48:48 |
| Message-ID: | f9f2744b-12cd-4698-917e-4a18c8038096@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 11/2/24 01:18, Nikita Malakhov wrote:
> I've corrected failing test and created a patch at Commitfest:
> https://commitfest.postgresql.org/51/5361/ <https://
> commitfest.postgresql.org/51/5361/>
I have played around with this feature, which looks promising for such a
tiny change. It provides a 'bottom boundary' recommendation for
appending subpaths, participating in the 'fractional branch' of paths.
As I see it works consistently with the plans, created for plain tables
filled with similar data.
According to the proposal to change SeqScan logic, IMO, Andy is right.
But it is a separate improvement because it wouldn't work in the case of
LIMIT 10 or 100, as the newly added regression tests demonstrate.
I think this feature gives sensible profit for partitionwise paths.
Pushing this knowledge into subpaths could help postgres_fdw to reduce
network traffic.
--
regards, Andrei Lepikhov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sutou Kouhei | 2024-12-06 07:20:42 | Re: confusing / inefficient "need_transcoding" handling in copy |
| Previous Message | Peter Smith | 2024-12-06 06:16:33 | Re: Parallel heap vacuum |