From: | Arne Roland <A(dot)Roland(at)index(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path |
Date: | 2021-06-04 00:10:25 |
Message-ID: | 920f0b3b5761410ab6833787211af250@index.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
thanks for the quick reply!
From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Sent: Thursday, June 3, 2021 20:11
To: Arne Roland; pgsql-hackers
Subject: Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path
> I haven't tested the parallel case, but I think we should sort out (3)
> get_cheapest_fractional_path_for_pathkeys as mentioned above.
>
Not sure what you refer to by "above" - it's probably better to reply
in-line to existing message, which makes it much cleared.
I was referring to one message above. I thought the thread was still short enough. Apparently to much time has passed. Sorry, I hope this mail is better. I was referring to my post from April:
________________________________
From: Arne Roland
Sent: Monday, April 26, 2021 13:00
To: Tomas Vondra; pgsql-hackers
Subject: Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path
>3) Not sure if get_cheapest_fractional_path_for_pathkeys should worry
> about require_parallel_safe, just like the other functions nearby.
I think it should. We have a ParallelAppend node after all.
I'm not really familiar with the way get_cheapest_fractional_path_for_pathkeys is used, but a quick search suggests to me, that build_minmax_path was thus far the only one using it. And minmax paths are never parallel safe anyway. I think that is the reason it doesn't do that already.
________________________________
From: Zhihong Yu <zyu(at)yugabyte(dot)com>
Sent: Thursday, June 3, 2021 22:50
To: Tomas Vondra
Cc: Arne Roland; pgsql-hackers
Subject: Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path
Hi,
In REL_11_STABLE branch, a search revealed the following:
src/backend/optimizer/path/pathkeys.c: * get_cheapest_fractional_path_for_pathkeys
src/backend/optimizer/path/pathkeys.c:get_cheapest_fractional_path_for_pathkeys(List *paths,
src/backend/optimizer/plan/planagg.c: get_cheapest_fractional_path_for_pathkeys(final_rel->pathlist,
src/include/optimizer/paths.h:extern Path *get_cheapest_fractional_path_for_pathkeys(List *paths,
It seems this function has been refactored out in subsequent releases.
FYI
Thanks for the info!
I doubt there is any interest to back patch this anywhere. My most ambitious dream would be getting this into pg 14.
I think, we only care about a parallel safety aware variant anyways, which afaict never existed.
________________________________
From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Sent: Thursday, June 3, 2021 22:57
To: Zhihong Yu
Cc: Arne Roland; pgsql-hackers
Subject: Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path
Actually, there are two comments
/* XXX maybe we should have startup_new_fractional? */
in the patch I posted - I completely forgot about that. But I think
that's a typo, I think - it should be
/* XXX maybe we should have startup_neq_fractional? */
and the new flag would work similarly to startup_neq_total, i.e. it's
pointless to add paths where startup == fractional cost.
At least I think that was the idea when I wrote the patch, it way too
long ago.
Sorry, I almost forgot about this myself. I only got reminded upon seeing that again with different queries/tables.
Just to be sure I get this correctly: You mean startup_gt_fractional (cost) as an additional condition, right?
Regards
Arne
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2021-06-04 00:19:09 | Re: [PATCH] Finally split StdRdOptions into HeapOptions and ToastOptions |
Previous Message | Michael Paquier | 2021-06-03 23:54:48 | Re: Move pg_attribute.attcompression to earlier in struct for reduced size? |