* get_useful_pathkeys_for_relation * Determine which orderings of a relation might be useful. * * Getting data in sorted order can be useful either because the requested * order matches the final output ordering for the overall query we're * planning, or because it enables an efficient merge join. Here, we try * to figure out which pathkeys to consider. */
| 902 | * to figure out which pathkeys to consider. |
| 903 | */ |
| 904 | static List * |
| 905 | get_useful_pathkeys_for_relation(PlannerInfo *root, RelOptInfo *rel) |
| 906 | { |
| 907 | List *useful_pathkeys_list = NIL; |
| 908 | List *useful_eclass_list; |
| 909 | PgFdwRelationInfo *fpinfo = (PgFdwRelationInfo *) rel->fdw_private; |
| 910 | EquivalenceClass *query_ec = NULL; |
| 911 | ListCell *lc; |
| 912 | |
| 913 | /* |
| 914 | * Pushing the query_pathkeys to the remote server is always worth |
| 915 | * considering, because it might let us avoid a local sort. |
| 916 | */ |
| 917 | fpinfo->qp_is_pushdown_safe = false; |
| 918 | if (root->query_pathkeys) |
| 919 | { |
| 920 | bool query_pathkeys_ok = true; |
| 921 | |
| 922 | foreach(lc, root->query_pathkeys) |
| 923 | { |
| 924 | PathKey *pathkey = (PathKey *) lfirst(lc); |
| 925 | |
| 926 | /* |
| 927 | * The planner and executor don't have any clever strategy for |
| 928 | * taking data sorted by a prefix of the query's pathkeys and |
| 929 | * getting it to be sorted by all of those pathkeys. We'll just |
| 930 | * end up resorting the entire data set. So, unless we can push |
| 931 | * down all of the query pathkeys, forget it. |
| 932 | */ |
| 933 | if (!is_foreign_pathkey(root, rel, pathkey)) |
| 934 | { |
| 935 | query_pathkeys_ok = false; |
| 936 | break; |
| 937 | } |
| 938 | } |
| 939 | |
| 940 | if (query_pathkeys_ok) |
| 941 | { |
| 942 | useful_pathkeys_list = list_make1(list_copy(root->query_pathkeys)); |
| 943 | fpinfo->qp_is_pushdown_safe = true; |
| 944 | } |
| 945 | } |
| 946 | |
| 947 | /* |
| 948 | * Even if we're not using remote estimates, having the remote side do the |
| 949 | * sort generally won't be any worse than doing it locally, and it might |
| 950 | * be much better if the remote side can generate data in the right order |
| 951 | * without needing a sort at all. However, what we're going to do next is |
| 952 | * try to generate pathkeys that seem promising for possible merge joins, |
| 953 | * and that's more speculative. A wrong choice might hurt quite a bit, so |
| 954 | * bail out if we can't use remote estimates. |
| 955 | */ |
| 956 | if (!fpinfo->use_remote_estimate) |
| 957 | return useful_pathkeys_list; |
| 958 | |
| 959 | /* Get the list of interesting EquivalenceClasses. */ |
| 960 | useful_eclass_list = get_useful_ecs_for_relation(root, rel); |
| 961 |
no test coverage detected