From: | Nikita Malakhov <hukutoc(at)gmail(dot)com> |
---|---|
To: | Andy Fan <zhihuifan1213(at)163(dot)com> |
Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, 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-10-28 19:50:26 |
Message-ID: | CAN-LCVN_o8hS=bUAR7oJgC+TJg+6oX44nkQbe6_PkJCAn5V_Yw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Andy, thank you, I've checked this thread out along with run-time partition
pruning.
I've spend some time hovering on the tuple_fraction field usage and would
disagree
with you on this topic - it is already used on the RelOptInfo level later
on, in
generate_orderedappend_paths()
I mean the following piece:
if (root->tuple_fraction > 0)
{
double path_fraction = (1.0 / root->tuple_fraction);
Path cheapest_consider_fraction;
cheapest_fractional =
get_cheapest_fractional_path_for_pathkeys(childrel->pathlist,
pathkeys, NULL, path_fraction);
...
function, so it does not seem incorrect to use its value for a single
relation in subquery -
I agree that we do not have accurate estimation at this level, but we could
use the one
we already have.
I've also tried hard to find an example where this patch could break
something,
but without success.
--
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2024-10-28 20:21:29 | Re: sunsetting md5 password support |
Previous Message | Nikita Malakhov | 2024-10-28 19:46:31 | Re: MergeAppend could consider sorting cheapest child path |