Hi!
Please check the following proposal (patch in attach).
The main idea is to reject only obviously worse paths (costs considerably
more
than compared one), and to pass pre-calculated startup cost to precheck
function
for more accurate comparison.
>
> --
Regards,
Nikita Malakhov
Postgres Profess
Hi!
I would rather do not exclude add_partial_path_precheck, but modify it to
check just path costs
and do not count key chains length:
foreach(p1, parent_rel->partial_pathlist)
{
Path *old_path = (Path *) lfirst(p1);
if (total_cost > old_path->total_cost * STD_FUZZ_FACTOR)
return
On 22/11/2024 18:12, Ba Jinsheng wrote:
I think the key difference is that the patch disables the usage of Hash
Join, which incurs a worse performance.
Discovering your case a little more I found out the origins of the
problem: Memoize+NestLoop was not chosen because top-query LIMIT node
wasn't
On 22/11/2024 18:12, Ba Jinsheng wrote:
I think the key difference is that the patch disables the usage of Hash
Join, which incurs a worse performance.
I see here a problem with a number of groups: when predicting it
incorrectly, Postgres doesn't use the Memoize node. Disabling HashJoin
puts Ne
