Re: Incorrect calculation of path fraction value in MergeAppend

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Junwang Zhao <zhjwpku(at)gmail(dot)com>
Cc: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Incorrect calculation of path fraction value in MergeAppend
Date: 2025-05-07 18:42:16
Message-ID: 3c83c594-6beb-414b-8059-f57e9a9eb0d7@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 7/5/2025 12:45, Álvaro Herrera wrote:
> On 2025-May-07, Andrei Lepikhov wrote:
>> The magic is how it finds a link to the thread. This time it doesn't
> Weird, that doesn't seem to work very well if you try to search for
> stuff. But if you just specify the Message-Id without clicking
> "search" then it works. So here you go:
> https://commitfest.postgresql.org/patch/5742/
Thanks! I think this memo should be pinned at the top of the page.

On 7/5/2025 17:35, Junwang Zhao wrote:
> + /* Convert absolute limit to a path fraction */
> + if (path_fraction >= 1.)
> + path_fraction /= childrel->rows;
>
> maybe add `&& childrel->rows > 0.` to the if condition to
> avoid potential crash. I'm not sure if `childrel->rows` will
> be 0 but I see get_cheapest_fractional_path did this.
You may look at the 76281aa for the reason. Also, looking into the code,
I see that it is impossible now to find more places with rows == 0
except for the Dummy result node. Moreover, it just doesn't make sense
in the case of append nodes: why should the optimiser spend resources
and consider paths if it is impossible to pull any tuples from the subplan?

So, I think checking assertion instead would be the better option. See
new version in the attachment.

--
regards, Andrei Lepikhov

Attachment Content-Type Size
v1-0001-Fix-tuple_fraction-calculation-for-merge-append-f.patch text/plain 3.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message marcos sicat 2025-05-07 18:58:59 Different behavior between v15 and v17 using WITH CTE
Previous Message Devrim Gündüz 2025-05-07 16:26:40 Re: BUG #18913: pgdg-redhat-repo-42.0-52PGDG.noarch: Cannot download, all mirrors were already tried without succes