| blob | fc65d81e2177ada3671a1fd1296280cd64a5e046 |
1 /*-------------------------------------------------------------------------
2 *
3 * postgres_fdw.c
4 * Foreign-data wrapper for remote PostgreSQL servers
5 *
6 * Portions Copyright (c) 2012-2024, PostgreSQL Global Development Group
7 *
8 * IDENTIFICATION
9 * contrib/postgres_fdw/postgres_fdw.c
10 *
11 *-------------------------------------------------------------------------
12 */
15 #include <limits.h>
54 PG_MODULE_MAGIC;
56 /* Default CPU cost to start up a foreign query. */
57 #define DEFAULT_FDW_STARTUP_COST 100.0
59 /* Default CPU cost to process 1 row (above and beyond cpu_tuple_cost). */
60 #define DEFAULT_FDW_TUPLE_COST 0.2
62 /* If no remote estimates, assume a sort costs 20% extra */
63 #define DEFAULT_FDW_SORT_MULTIPLIER 1.2
65 /*
66 * Indexes of FDW-private information stored in fdw_private lists.
67 *
68 * These items are indexed with the enum FdwScanPrivateIndex, so an item
69 * can be fetched with list_nth(). For example, to get the SELECT statement:
70 * sql = strVal(list_nth(fdw_private, FdwScanPrivateSelectSql));
71 */
72 enum FdwScanPrivateIndex
73 {
74 /* SQL statement to execute remotely (as a String node) */
75 FdwScanPrivateSelectSql,
76 /* Integer list of attribute numbers retrieved by the SELECT */
77 FdwScanPrivateRetrievedAttrs,
78 /* Integer representing the desired fetch_size */
79 FdwScanPrivateFetchSize,
81 /*
82 * String describing join i.e. names of relations being joined and types
83 * of join, added when the scan is join
84 */
85 FdwScanPrivateRelations,
86 };
88 /*
89 * Similarly, this enum describes what's kept in the fdw_private list for
90 * a ModifyTable node referencing a postgres_fdw foreign table. We store:
91 *
92 * 1) INSERT/UPDATE/DELETE statement text to be sent to the remote server
93 * 2) Integer list of target attribute numbers for INSERT/UPDATE
94 * (NIL for a DELETE)
95 * 3) Length till the end of VALUES clause for INSERT
96 * (-1 for a DELETE/UPDATE)
97 * 4) Boolean flag showing if the remote query has a RETURNING clause
98 * 5) Integer list of attribute numbers retrieved by RETURNING, if any
99 */
100 enum FdwModifyPrivateIndex
101 {
102 /* SQL statement to execute remotely (as a String node) */
103 FdwModifyPrivateUpdateSql,
104 /* Integer list of target attribute numbers for INSERT/UPDATE */
105 FdwModifyPrivateTargetAttnums,
106 /* Length till the end of VALUES clause (as an Integer node) */
107 FdwModifyPrivateLen,
108 /* has-returning flag (as a Boolean node) */
109 FdwModifyPrivateHasReturning,
110 /* Integer list of attribute numbers retrieved by RETURNING */
111 FdwModifyPrivateRetrievedAttrs,
112 };
114 /*
115 * Similarly, this enum describes what's kept in the fdw_private list for
116 * a ForeignScan node that modifies a foreign table directly. We store:
117 *
118 * 1) UPDATE/DELETE statement text to be sent to the remote server
119 * 2) Boolean flag showing if the remote query has a RETURNING clause
120 * 3) Integer list of attribute numbers retrieved by RETURNING, if any
121 * 4) Boolean flag showing if we set the command es_processed
122 */
123 enum FdwDirectModifyPrivateIndex
124 {
125 /* SQL statement to execute remotely (as a String node) */
126 FdwDirectModifyPrivateUpdateSql,
127 /* has-returning flag (as a Boolean node) */
128 FdwDirectModifyPrivateHasReturning,
129 /* Integer list of attribute numbers retrieved by RETURNING */
130 FdwDirectModifyPrivateRetrievedAttrs,
131 /* set-processed flag (as a Boolean node) */
132 FdwDirectModifyPrivateSetProcessed,
133 };
135 /*
136 * Execution state of a foreign scan using postgres_fdw.
137 */
139 {
141 * for a foreign join scan. */
145 /* extracted fdw_private data */
149 /* for remote query execution */
159 /* for storing result tuples */
164 /* batch-level state, for optimizing rewinds and avoiding useless fetch */
168 /* for asynchronous execution */
171 /* working memory contexts */
178 /*
179 * Execution state of a foreign insert/update/delete operation.
180 */
182 {
186 /* for remote query execution */
191 /* extracted fdw_private data */
200 /* info about parameters for prepared statement */
205 /* batch operation stuff */
208 /* working memory context */
211 /* for update row movement if subplan result rel */
213 * created */
216 /*
217 * Execution state of a foreign scan that modifies a foreign table directly.
218 */
220 {
224 /* extracted fdw_private data */
230 /* for remote query execution */
238 /* for storing result tuples */
248 /* working memory context */
252 /*
253 * Workspace for analyzing a foreign table.
254 */
256 {
261 /* collected sample rows */
266 /* for random sampling */
271 /* working memory contexts */
276 /*
277 * This enum describes what's kept in the fdw_private list for a ForeignPath.
278 * We store:
279 *
280 * 1) Boolean flag showing if the remote query has the final sort
281 * 2) Boolean flag showing if the remote query has the LIMIT clause
282 */
283 enum FdwPathPrivateIndex
284 {
285 /* has-final-sort flag (as a Boolean node) */
286 FdwPathPrivateHasFinalSort,
287 /* has-limit flag (as a Boolean node) */
288 FdwPathPrivateHasLimit,
289 };
291 /* Struct for extra information passed to estimate_path_cost_size() */
293 {
298 int64 count_est;
299 int64 offset_est;
302 /*
303 * Identify the attribute where data conversion fails.
304 */
306 {
312 /* Callback argument for ec_member_matches_foreign */
314 {
319 /*
320 * SQL functions
321 */
324 /*
325 * FDW callback routines
326 */
329 Oid foreigntableid);
332 Oid foreigntableid);
335 Oid foreigntableid,
345 Index rtindex,
347 Relation target_relation);
350 Index resultRelation,
384 Index resultRelation,
399 DropBehavior behavior,
405 Oid serverOid);
410 JoinType jointype,
415 UpperRelationKind stage,
424 /*
425 * Helper functions
426 */
457 CmdType operation,
466 CmdType operation,
472 ItemPointer tupleid,
486 Index rtindex);
512 Relation rel,
516 MemoryContext temp_context);
547 /*
548 * Foreign-data wrapper handler function: return a struct with pointers
549 * to my callback routines.
550 */
551 Datum
553 {
556 /* Functions for scanning foreign tables */
565 /* Functions for updating foreign tables */
583 /* Function for EvalPlanQual rechecks */
585 /* Support functions for EXPLAIN */
590 /* Support function for TRUNCATE */
593 /* Support functions for ANALYZE */
596 /* Support functions for IMPORT FOREIGN SCHEMA */
599 /* Support functions for join push-down */
602 /* Support functions for upper relation push-down */
605 /* Support functions for asynchronous execution */
612 }
614 /*
615 * postgresGetForeignRelSize
616 * Estimate # of rows and width of the result of the scan
617 *
618 * We should consider the effect of all baserestrictinfo clauses here, but
619 * not any join clauses.
620 */
621 static void
624 Oid foreigntableid)
625 {
629 /*
630 * We use PgFdwRelationInfo to pass various information to subsequent
631 * functions.
632 */
636 /* Base foreign tables need to be pushed down always. */
639 /* Look up foreign-table catalog info. */
643 /*
644 * Extract user-settable option values. Note that per-table settings of
645 * use_remote_estimate, fetch_size and async_capable override per-server
646 * settings of them, respectively.
647 */
658 /*
659 * If the table or the server is configured to use remote estimates,
660 * identify which user to do remote access as during planning. This
661 * should match what ExecCheckPermissions() does. If we fail due to lack
662 * of permissions, the query would have failed at runtime anyway.
663 */
665 {
666 Oid userid;
670 }
671 else
674 /*
675 * Identify which baserestrictinfo clauses can be sent to the remote
676 * server and which can't.
677 */
681 /*
682 * Identify which attributes will need to be retrieved from the remote
683 * server. These include all attrs needed for joins or final output, plus
684 * all attrs used in the local_conds. (Note: if we end up using a
685 * parameterized scan, it's possible that some of the join clauses will be
686 * sent to the remote and thus we wouldn't really need to retrieve the
687 * columns used in them. Doesn't seem worth detecting that case though.)
688 */
693 {
698 }
700 /*
701 * Compute the selectivity and cost of the local_conds, so we don't have
702 * to do it over again for each path. The best we can do for these
703 * conditions is to estimate selectivity on the basis of local statistics.
704 */
708 JOIN_INNER,
709 NULL);
713 /*
714 * Set # of retrieved rows and cached relation costs to some negative
715 * value, so that we can detect when they are set to some sensible values,
716 * during one (usually the first) of the calls to estimate_path_cost_size.
717 */
722 /*
723 * If the table or the server is configured to use remote estimates,
724 * connect to the foreign server and execute EXPLAIN to estimate the
725 * number of rows selected by the restriction clauses, as well as the
726 * average row width. Otherwise, estimate using whatever statistics we
727 * have locally, in a way similar to ordinary tables.
728 */
730 {
731 /*
732 * Get cost/size estimates with help of remote server. Save the
733 * values in fpinfo so we don't need to do it again to generate the
734 * basic foreign path.
735 */
740 /* Report estimated baserel size to planner. */
743 }
744 else
745 {
746 /*
747 * If the foreign table has never been ANALYZEd, it will have
748 * reltuples < 0, meaning "unknown". We can't do much if we're not
749 * allowed to consult the remote server, but we can use a hack similar
750 * to plancat.c's treatment of empty relations: use a minimum size
751 * estimate of 10 pages, and divide by the column-datatype-based width
752 * estimate to get the corresponding number of tuples.
753 */
755 {
760 }
762 /* Estimate baserel size as best we can with local statistics. */
765 /* Fill in basically-bogus cost estimates for use later. */
769 }
771 /*
772 * fpinfo->relation_name gets the numeric rangetable index of the foreign
773 * table RTE. (If this query gets EXPLAIN'd, we'll convert that to a
774 * human-readable string at that time.)
775 */
778 /* No outer and inner relations. */
783 /* Set the relation index. */
785 }
787 /*
788 * get_useful_ecs_for_relation
789 * Determine which EquivalenceClasses might be involved in useful
790 * orderings of this relation.
791 *
792 * This function is in some respects a mirror image of the core function
793 * pathkeys_useful_for_merging: for a regular table, we know what indexes
794 * we have and want to test whether any of them are useful. For a foreign
795 * table, we don't know what indexes are present on the remote side but
796 * want to speculate about which ones we'd like to use if they existed.
797 *
798 * This function returns a list of potentially-useful equivalence classes,
799 * but it does not guarantee that an EquivalenceMember exists which contains
800 * Vars only from the given relation. For example, given ft1 JOIN t1 ON
801 * ft1.x + t1.x = 0, this function will say that the equivalence class
802 * containing ft1.x + t1.x is potentially useful. Supposing ft1 is remote and
803 * t1 is local (or on a different server), it will turn out that no useful
804 * ORDER BY clause can be generated. It's not our job to figure that out
805 * here; we're only interested in identifying relevant ECs.
806 */
809 {
812 Relids relids;
814 /*
815 * First, consider whether any active EC is potentially useful for a merge
816 * join against this relation.
817 */
819 {
821 {
826 }
827 }
829 /*
830 * Next, consider whether there are any non-EC derivable join clauses that
831 * are merge-joinable. If the joininfo list is empty, we can exit
832 * quickly.
833 */
837 /* If this is a child rel, we must use the topmost parent rel to search. */
839 {
842 }
843 else
846 /* Check each join clause in turn. */
848 {
851 /* Consider only mergejoinable clauses */
855 /* Make sure we've got canonical ECs. */
858 /*
859 * restrictinfo->mergeopfamilies != NIL is sufficient to guarantee
860 * that left_ec and right_ec will be initialized, per comments in
861 * distribute_qual_to_rels.
862 *
863 * We want to identify which side of this merge-joinable clause
864 * contains columns from the relation produced by this RelOptInfo. We
865 * test for overlap, not containment, because there could be extra
866 * relations on either side. For example, suppose we've got something
867 * like ((A JOIN B ON A.x = B.x) JOIN C ON A.y = C.y) LEFT JOIN D ON
868 * A.y = D.y. The input rel might be the joinrel between A and B, and
869 * we'll consider the join clause A.y = D.y. relids contains a
870 * relation not involved in the join class (B) and the equivalence
871 * class for the left-hand side of the clause contains a relation not
872 * involved in the input rel (C). Despite the fact that we have only
873 * overlap and not containment in either direction, A.y is potentially
874 * useful as a sort column.
875 *
876 * Note that it's even possible that relids overlaps neither side of
877 * the join clause. For example, consider A LEFT JOIN B ON A.x = B.x
878 * AND A.x = 1. The clause A.x = 1 will appear in B's joininfo list,
879 * but overlaps neither side of B. In that case, we just skip this
880 * join clause, since it doesn't suggest a useful sort order for this
881 * relation.
882 */
889 }
892 }
894 /*
895 * get_useful_pathkeys_for_relation
896 * Determine which orderings of a relation might be useful.
897 *
898 * Getting data in sorted order can be useful either because the requested
899 * order matches the final output ordering for the overall query we're
900 * planning, or because it enables an efficient merge join. Here, we try
901 * to figure out which pathkeys to consider.
902 */
905 {
912 /*
913 * Pushing the query_pathkeys to the remote server is always worth
914 * considering, because it might let us avoid a local sort.
915 */
918 {
922 {
925 /*
926 * The planner and executor don't have any clever strategy for
927 * taking data sorted by a prefix of the query's pathkeys and
928 * getting it to be sorted by all of those pathkeys. We'll just
929 * end up resorting the entire data set. So, unless we can push
930 * down all of the query pathkeys, forget it.
931 */
933 {
936 }
937 }
940 {
943 }
944 }
946 /*
947 * Even if we're not using remote estimates, having the remote side do the
948 * sort generally won't be any worse than doing it locally, and it might
949 * be much better if the remote side can generate data in the right order
950 * without needing a sort at all. However, what we're going to do next is
951 * try to generate pathkeys that seem promising for possible merge joins,
952 * and that's more speculative. A wrong choice might hurt quite a bit, so
953 * bail out if we can't use remote estimates.
954 */
958 /* Get the list of interesting EquivalenceClasses. */
961 /* Extract unique EC for query, if any, so we don't consider it again. */
963 {
967 }
969 /*
970 * As a heuristic, the only pathkeys we consider here are those of length
971 * one. It's surely possible to consider more, but since each one we
972 * choose to consider will generate a round-trip to the remote side, we
973 * need to be a bit cautious here. It would sure be nice to have a local
974 * cache of information about remote index definitions...
975 */
977 {
981 /* If redundant with what we did above, skip it. */
985 /* Can't push down the sort if the EC's opfamily is not shippable. */
990 /* If no pushable expression for this rel, skip it. */
994 /* Looks like we can generate a pathkey, so let's do it. */
997 BTLessStrategyNumber,
1001 }
1004 }
1006 /*
1007 * postgresGetForeignPaths
1008 * Create possible scan paths for a scan on the foreign table
1009 */
1010 static void
1013 Oid foreigntableid)
1014 {
1020 /*
1021 * Create simplest ForeignScan path node and add it to baserel. This path
1022 * corresponds to SeqScan path of regular tables (though depending on what
1023 * baserestrict conditions we were able to send to remote, there might
1024 * actually be an indexscan happening there). We already did all the work
1025 * to estimate cost and size of this path.
1026 *
1027 * Although this path uses no join clauses, it could still have required
1028 * parameterization due to LATERAL refs in its tlist.
1029 */
1042 /* Add paths with pathkeys */
1045 /*
1046 * If we're not using remote estimates, stop here. We have no way to
1047 * estimate whether any join clauses would be worth sending across, so
1048 * don't bother building parameterized paths.
1049 */
1053 /*
1054 * Thumb through all join clauses for the rel to identify which outer
1055 * relations could supply one or more safe-to-send-to-remote join clauses.
1056 * We'll build a parameterized path for each such outer relation.
1057 *
1058 * It's convenient to manage this by representing each candidate outer
1059 * relation by the ParamPathInfo node for it. We can then use the
1060 * ppi_clauses list in the ParamPathInfo node directly as a list of the
1061 * interesting join clauses for that rel. This takes care of the
1062 * possibility that there are multiple safe join clauses for such a rel,
1063 * and also ensures that we account for unsafe join clauses that we'll
1064 * still have to enforce locally (since the parameterized-path machinery
1065 * insists that we handle all movable clauses).
1066 */
1069 {
1071 Relids required_outer;
1074 /* Check if clause can be moved to this rel */
1078 /* See if it is safe to send to remote */
1082 /* Calculate required outer rels for the resulting path */
1085 /* We do not want the foreign rel itself listed in required_outer */
1088 /*
1089 * required_outer probably can't be empty here, but if it were, we
1090 * couldn't make a parameterized path.
1091 */
1095 /* Get the ParamPathInfo */
1097 required_outer);
1100 /*
1101 * Add it to list unless we already have it. Testing pointer equality
1102 * is OK since get_baserel_parampathinfo won't make duplicates.
1103 */
1105 }
1107 /*
1108 * The above scan examined only "generic" join clauses, not those that
1109 * were absorbed into EquivalenceClauses. See if we can make anything out
1110 * of EquivalenceClauses.
1111 */
1113 {
1114 /*
1115 * We repeatedly scan the eclass list looking for column references
1116 * (or expressions) belonging to the foreign rel. Each time we find
1117 * one, we generate a list of equivalence joinclauses for it, and then
1118 * see if any are safe to send to the remote. Repeat till there are
1119 * no more candidate EC members.
1120 */
1121 ec_member_foreign_arg arg;
1125 {
1128 /* Make clauses, skipping any that join to lateral_referencers */
1131 baserel,
1132 ec_member_matches_foreign,
1136 /* Done if there are no more expressions in the foreign rel */
1138 {
1141 }
1143 /* Scan the extracted join clauses */
1145 {
1147 Relids required_outer;
1150 /* Check if clause can be moved to this rel */
1154 /* See if it is safe to send to remote */
1158 /* Calculate required outer rels for the resulting path */
1165 /* Get the ParamPathInfo */
1167 required_outer);
1170 /* Add it to list unless we already have it */
1172 }
1174 /* Try again, now ignoring the expression we found this time */
1176 }
1177 }
1179 /*
1180 * Now build a path for each useful outer relation.
1181 */
1183 {
1187 Cost startup_cost;
1188 Cost total_cost;
1190 /* Get a cost estimate from the remote */
1196 /*
1197 * ppi_rows currently won't get looked at by anything, but still we
1198 * may as well ensure that it matches our idea of the rowcount.
1199 */
1202 /* Make the path */
1205 rows,
1206 startup_cost,
1207 total_cost,
1210 NULL,
1214 }
1215 }
1217 /*
1218 * postgresGetForeignPlan
1219 * Create ForeignScan plan node which implements selected best path
1220 */
1224 Oid foreigntableid,
1229 {
1231 Index scan_relid;
1239 StringInfoData sql;
1244 /*
1245 * Get FDW private data created by postgresGetForeignUpperPaths(), if any.
1246 */
1248 {
1250 FdwPathPrivateHasFinalSort));
1252 FdwPathPrivateHasLimit));
1253 }
1256 {
1257 /*
1258 * For base relations, set scan_relid as the relid of the relation.
1259 */
1262 /*
1263 * In a base-relation scan, we must apply the given scan_clauses.
1264 *
1265 * Separate the scan_clauses into those that can be executed remotely
1266 * and those that can't. baserestrictinfo clauses that were
1267 * previously determined to be safe or unsafe by classifyConditions
1268 * are found in fpinfo->remote_conds and fpinfo->local_conds. Anything
1269 * else in the scan_clauses list will be a join clause, which we have
1270 * to check for remote-safety.
1271 *
1272 * Note: the join clauses we see here should be the exact same ones
1273 * previously examined by postgresGetForeignPaths. Possibly it'd be
1274 * worth passing forward the classification work done then, rather
1275 * than repeating it here.
1276 *
1277 * This code must match "extract_actual_clauses(scan_clauses, false)"
1278 * except for the additional decision about remote versus local
1279 * execution.
1280 */
1282 {
1285 /* Ignore any pseudoconstants, they're dealt with elsewhere */
1295 else
1297 }
1299 /*
1300 * For a base-relation scan, we have to support EPQ recheck, which
1301 * should recheck all the remote quals.
1302 */
1304 }
1305 else
1306 {
1307 /*
1308 * Join relation or upper relation - set scan_relid to 0.
1309 */
1312 /*
1313 * For a join rel, baserestrictinfo is NIL and we are not considering
1314 * parameterization right now, so there should be no scan_clauses for
1315 * a joinrel or an upper rel either.
1316 */
1319 /*
1320 * Instead we get the conditions to apply from the fdw_private
1321 * structure.
1322 */
1326 /*
1327 * We leave fdw_recheck_quals empty in this case, since we never need
1328 * to apply EPQ recheck clauses. In the case of a joinrel, EPQ
1329 * recheck is handled elsewhere --- see postgresGetForeignJoinPaths().
1330 * If we're planning an upperrel (ie, remote grouping or aggregation)
1331 * then there's no EPQ to do because SELECT FOR UPDATE wouldn't be
1332 * allowed, and indeed we *can't* put the remote clauses into
1333 * fdw_recheck_quals because the unaggregated Vars won't be available
1334 * locally.
1335 */
1337 /* Build the list of columns to be fetched from the foreign server. */
1340 /*
1341 * Ensure that the outer plan produces a tuple whose descriptor
1342 * matches our scan tuple slot. Also, remove the local conditions
1343 * from outer plan's quals, lest they be evaluated twice, once by the
1344 * local plan and once by the scan.
1345 */
1347 {
1348 /*
1349 * Right now, we only consider grouping and aggregation beyond
1350 * joins. Queries involving aggregates or grouping do not require
1351 * EPQ mechanism, hence should not have an outer plan here.
1352 */
1355 /*
1356 * First, update the plan's qual list if possible. In some cases
1357 * the quals might be enforced below the topmost plan level, in
1358 * which case we'll fail to remove them; it's not worth working
1359 * harder than this.
1360 */
1362 {
1367 /*
1368 * For an inner join the local conditions of foreign scan plan
1369 * can be part of the joinquals as well. (They might also be
1370 * in the mergequals or hashquals, but we can't touch those
1371 * without breaking the plan.)
1372 */
1376 {
1381 qual);
1382 }
1383 }
1385 /*
1386 * Now fix the subplan's tlist --- this might result in inserting
1387 * a Result node atop the plan tree.
1388 */
1391 }
1392 }
1394 /*
1395 * Build the query string to be sent for execution, and identify
1396 * expressions to be sent as parameters.
1397 */
1404 /* Remember remote_exprs for possible use by postgresPlanDirectModify */
1407 /*
1408 * Build the fdw_private list that will be available to the executor.
1409 * Items in the list must match order in enum FdwScanPrivateIndex.
1410 */
1412 retrieved_attrs,
1418 /*
1419 * Create the ForeignScan node for the given relation.
1420 *
1421 * Note that the remote parameter expressions are stored in the fdw_exprs
1422 * field of the finished plan node; we can't keep them in private state
1423 * because then they wouldn't be subject to later planner processing.
1424 */
1426 local_exprs,
1427 scan_relid,
1428 params_list,
1429 fdw_private,
1430 fdw_scan_tlist,
1431 fdw_recheck_quals,
1432 outer_plan);
1433 }
1435 /*
1436 * Construct a tuple descriptor for the scan tuples handled by a foreign join.
1437 */
1438 static TupleDesc
1440 {
1443 TupleDesc tupdesc;
1445 /*
1446 * The core code has already set up a scan tuple slot based on
1447 * fsplan->fdw_scan_tlist, and this slot's tupdesc is mostly good enough,
1448 * but there's one case where it isn't. If we have any whole-row row
1449 * identifier Vars, they may have vartype RECORD, and we need to replace
1450 * that with the associated table's actual composite type. This ensures
1451 * that when we read those ROW() expression values from the remote server,
1452 * we can convert them to a composite type the local server knows.
1453 */
1456 {
1460 Oid reltype;
1462 /* Nothing to do if it's not a generic RECORD attribute */
1466 /*
1467 * If we can't identify the referenced table, do nothing. This'll
1468 * likely lead to failure later, but perhaps we can muddle through.
1469 */
1481 /* shouldn't need to change anything else */
1482 }
1484 }
1486 /*
1487 * postgresBeginForeignScan
1488 * Initiate an executor scan of a foreign PostgreSQL table.
1489 */
1490 static void
1492 {
1497 Oid userid;
1503 /*
1504 * Do nothing in EXPLAIN (no ANALYZE) case. node->fdw_state stays NULL.
1505 */
1509 /*
1510 * We'll save private state in node->fdw_state.
1511 */
1515 /*
1516 * Identify which user to do the remote access as. This should match what
1517 * ExecCheckPermissions() does.
1518 */
1522 else
1526 /* Get info about foreign table. */
1530 /*
1531 * Get connection to the foreign server. Connection manager will
1532 * establish new connection if necessary.
1533 */
1536 /* Assign a unique ID for my cursor */
1540 /* Get private info created by planner functions. */
1542 FdwScanPrivateSelectSql));
1544 FdwScanPrivateRetrievedAttrs);
1546 FdwScanPrivateFetchSize));
1548 /* Create contexts for batches of tuples and per-tuple temp workspace. */
1551 ALLOCSET_DEFAULT_SIZES);
1554 ALLOCSET_SMALL_SIZES);
1556 /*
1557 * Get info we'll need for converting data fetched from the foreign server
1558 * into local representation and error reporting during that process.
1559 */
1561 {
1564 }
1565 else
1566 {
1569 }
1573 /*
1574 * Prepare for processing of parameters used in remote query, if any.
1575 */
1581 numParams,
1586 /* Set the async-capable flag */
1588 }
1590 /*
1591 * postgresIterateForeignScan
1592 * Retrieve next row from the result set, or clear tuple slot to indicate
1593 * EOF.
1594 */
1597 {
1601 /*
1602 * In sync mode, if this is the first call after Begin or ReScan, we need
1603 * to create the cursor on the remote side. In async mode, we would have
1604 * already created the cursor before we get here, even if this is the
1605 * first call after Begin or ReScan.
1606 */
1610 /*
1611 * Get some more tuples, if we've run out.
1612 */
1614 {
1615 /* In async mode, just clear tuple slot. */
1618 /* No point in another fetch if we already detected EOF, though. */
1621 /* If we didn't get any tuples, must be end of data. */
1624 }
1626 /*
1627 * Return the next tuple.
1628 */
1630 slot,
1634 }
1636 /*
1637 * postgresReScanForeignScan
1638 * Restart the scan.
1639 */
1640 static void
1642 {
1647 /* If we haven't created the cursor yet, nothing to do. */
1651 /*
1652 * If the node is async-capable, and an asynchronous fetch for it has
1653 * begun, the asynchronous fetch might not have yet completed. Check if
1654 * the node is async-capable, and an asynchronous fetch for it is still in
1655 * progress; if so, complete the asynchronous fetch before restarting the
1656 * scan.
1657 */
1663 /*
1664 * If any internal parameters affecting this node have changed, we'd
1665 * better destroy and recreate the cursor. Otherwise, if the remote
1666 * server is v14 or older, rewinding it should be good enough; if not,
1667 * rewind is only allowed for scrollable cursors, but we don't have a way
1668 * to check the scrollability of it, so destroy and recreate it in any
1669 * case. If we've only fetched zero or one batch, we needn't even rewind
1670 * the cursor, just rescan what we have.
1671 */
1673 {
1677 }
1679 {
1683 else
1684 {
1688 }
1689 }
1690 else
1691 {
1692 /* Easy: just rescan what we already have in memory, if anything */
1695 }
1697 /*
1698 * We don't use a PG_TRY block here, so be careful not to throw error
1699 * without releasing the PGresult.
1700 */
1706 /* Now force a fresh FETCH. */
1712 }
1714 /*
1715 * postgresEndForeignScan
1716 * Finish scanning foreign table and dispose objects used for this scan
1717 */
1718 static void
1720 {
1723 /* if fsstate is NULL, we are in EXPLAIN; nothing to do */
1727 /* Close the cursor if open, to prevent accumulation of cursors */
1732 /* Release remote connection */
1736 /* MemoryContexts will be deleted automatically. */
1737 }
1739 /*
1740 * postgresAddForeignUpdateTargets
1741 * Add resjunk column(s) needed for update/delete on a foreign table
1742 */
1743 static void
1745 Index rtindex,
1747 Relation target_relation)
1748 {
1751 /*
1752 * In postgres_fdw, what we need is the ctid, same as for a regular table.
1753 */
1755 /* Make a Var representing the desired value */
1757 SelfItemPointerAttributeNumber,
1758 TIDOID,
1760 InvalidOid,
1763 /* Register it as a row-identity column needed by this target rel */
1765 }
1767 /*
1768 * postgresPlanForeignModify
1769 * Plan an insert/update/delete operation on a foreign table
1770 */
1774 Index resultRelation,
1776 {
1779 Relation rel;
1780 StringInfoData sql;
1790 /*
1791 * Core code already has some lock on each rel being planned, so we can
1792 * use NoLock here.
1793 */
1796 /*
1797 * In an INSERT, we transmit all columns that are defined in the foreign
1798 * table. In an UPDATE, if there are BEFORE ROW UPDATE triggers on the
1799 * foreign table, we transmit all columns like INSERT; else we transmit
1800 * only columns that were explicitly targets of the UPDATE, so as to avoid
1801 * unnecessary data transmission. (We can't do that for INSERT since we
1802 * would miss sending default values for columns not listed in the source
1803 * statement, and for UPDATE if there are BEFORE ROW UPDATE triggers since
1804 * those triggers might change values for non-target columns, in which
1805 * case we would miss sending changed values for those columns.)
1806 */
1811 {
1816 {
1821 }
1822 }
1824 {
1831 {
1832 /* bit numbers are offset by FirstLowInvalidHeapAttributeNumber */
1838 }
1839 }
1841 /*
1842 * Extract the relevant WITH CHECK OPTION list if any.
1843 */
1846 subplan_index);
1848 /*
1849 * Extract the relevant RETURNING list if any.
1850 */
1854 /*
1855 * ON CONFLICT DO UPDATE and DO NOTHING case with inference specification
1856 * should have already been rejected in the optimizer, as presently there
1857 * is no way to recognize an arbiter index on a foreign table. Only DO
1858 * NOTHING is supported without an inference specification.
1859 */
1866 /*
1867 * Construct the SQL command string.
1868 */
1870 {
1879 targetAttrs,
1885 returningList,
1891 }
1895 /*
1896 * Build the fdw_private list that will be available to the executor.
1897 * Items in the list must match enum FdwModifyPrivateIndex, above.
1898 */
1900 targetAttrs,
1903 retrieved_attrs);
1904 }
1906 /*
1907 * postgresBeginForeignModify
1908 * Begin an insert/update/delete operation on a foreign table
1909 */
1910 static void
1916 {
1925 /*
1926 * Do nothing in EXPLAIN (no ANALYZE) case. resultRelInfo->ri_FdwState
1927 * stays NULL.
1928 */
1932 /* Deconstruct fdw_private data. */
1934 FdwModifyPrivateUpdateSql));
1936 FdwModifyPrivateTargetAttnums);
1938 FdwModifyPrivateLen));
1940 FdwModifyPrivateHasReturning));
1942 FdwModifyPrivateRetrievedAttrs);
1944 /* Find RTE. */
1948 /* Construct an execution state. */
1950 rte,
1951 resultRelInfo,
1954 query,
1955 target_attrs,
1956 values_end_len,
1957 has_returning,
1958 retrieved_attrs);
1961 }
1963 /*
1964 * postgresExecForeignInsert
1965 * Insert one row into a foreign table
1966 */
1972 {
1977 /*
1978 * If the fmstate has aux_fmstate set, use the aux_fmstate (see
1979 * postgresBeginForeignInsert())
1980 */
1985 /* Revert that change */
1990 }
1992 /*
1993 * postgresExecForeignBatchInsert
1994 * Insert multiple rows into a foreign table
1995 */
2002 {
2006 /*
2007 * If the fmstate has aux_fmstate set, use the aux_fmstate (see
2008 * postgresBeginForeignInsert())
2009 */
2014 /* Revert that change */
2019 }
2021 /*
2022 * postgresGetForeignModifyBatchSize
2023 * Determine the maximum number of tuples that can be inserted in bulk
2024 *
2025 * Returns the batch size specified for server or table. When batching is not
2026 * allowed (e.g. for tables with BEFORE/AFTER ROW triggers or with RETURNING
2027 * clause), returns 1.
2028 */
2029 static int
2031 {
2035 /* should be called only once */
2038 /*
2039 * Should never get called when the insert is being performed on a table
2040 * that is also among the target relations of an UPDATE operation, because
2041 * postgresBeginForeignInsert() currently rejects such insert attempts.
2042 */
2045 /*
2046 * In EXPLAIN without ANALYZE, ri_FdwState is NULL, so we have to lookup
2047 * the option directly in server/table options. Otherwise just use the
2048 * value we determined earlier.
2049 */
2052 else
2055 /*
2056 * Disable batching when we have to use RETURNING, there are any
2057 * BEFORE/AFTER ROW INSERT triggers on the foreign table, or there are any
2058 * WITH CHECK OPTION constraints from parent views.
2059 *
2060 * When there are any BEFORE ROW INSERT triggers on the table, we can't
2061 * support it, because such triggers might query the table we're inserting
2062 * into and act differently if the tuples that have already been processed
2063 * and prepared for insertion are not there.
2064 */
2072 /*
2073 * If the foreign table has no columns, disable batching as the INSERT
2074 * syntax doesn't allow batching multiple empty rows into a zero-column
2075 * table in a single statement. This is needed for COPY FROM, in which
2076 * case fmstate must be non-NULL.
2077 */
2081 /*
2082 * Otherwise use the batch size specified for server/table. The number of
2083 * parameters in a batch is limited to 65535 (uint16), so make sure we
2084 * don't exceed this limit by using the maximum batch_size possible.
2085 */
2090 }
2092 /*
2093 * postgresExecForeignUpdate
2094 * Update one row in a foreign table
2095 */
2101 {
2109 }
2111 /*
2112 * postgresExecForeignDelete
2113 * Delete one row from a foreign table
2114 */
2120 {
2128 }
2130 /*
2131 * postgresEndForeignModify
2132 * Finish an insert/update/delete operation on a foreign table
2133 */
2134 static void
2137 {
2140 /* If fmstate is NULL, we are in EXPLAIN; nothing to do */
2144 /* Destroy the execution state */
2146 }
2148 /*
2149 * postgresBeginForeignInsert
2150 * Begin an insert operation on a foreign table
2151 */
2152 static void
2155 {
2159 Index resultRelation;
2165 StringInfoData sql;
2170 /*
2171 * If the foreign table we are about to insert routed rows into is also an
2172 * UPDATE subplan result rel that will be updated later, proceeding with
2173 * the INSERT will result in the later UPDATE incorrectly modifying those
2174 * routed rows, so prevent the INSERT --- it would be nice if we could
2175 * handle this case; but for now, throw an error for safety.
2176 */
2187 /* We transmit all columns that are defined in the foreign table. */
2189 {
2194 }
2196 /* Check if we add the ON CONFLICT clause to the remote query. */
2198 {
2201 /* We only support DO NOTHING without an inference specification. */
2207 }
2209 /*
2210 * If the foreign table is a partition that doesn't have a corresponding
2211 * RTE entry, we need to create a new RTE describing the foreign table for
2212 * use by deparseInsertSql and create_foreign_modify() below, after first
2213 * copying the parent's RTE and modifying some fields to describe the
2214 * foreign partition to work on. However, if this is invoked by UPDATE,
2215 * the existing RTE may already correspond to this partition if it is one
2216 * of the UPDATE subplan target rels; in that case, we can just use the
2217 * existing RTE as-is.
2218 */
2220 {
2228 /*
2229 * For UPDATE, we must use the RT index of the first subplan target
2230 * rel's RTE, because the core code would have built expressions for
2231 * the partition, such as RETURNING, using that RT index as varno of
2232 * Vars contained in those expressions.
2233 */
2237 else
2239 }
2240 else
2241 {
2244 }
2246 /* Construct the SQL command string. */
2252 /* Construct an execution state. */
2254 rte,
2255 resultRelInfo,
2256 CMD_INSERT,
2257 NULL,
2259 targetAttrs,
2260 values_end_len,
2262 retrieved_attrs);
2264 /*
2265 * If the given resultRelInfo already has PgFdwModifyState set, it means
2266 * the foreign table is an UPDATE subplan result rel; in which case, store
2267 * the resulting state into the aux_fmstate of the PgFdwModifyState.
2268 */
2270 {
2274 }
2275 else
2277 }
2279 /*
2280 * postgresEndForeignInsert
2281 * Finish an insert operation on a foreign table
2282 */
2283 static void
2286 {
2291 /*
2292 * If the fmstate has aux_fmstate set, get the aux_fmstate (see
2293 * postgresBeginForeignInsert())
2294 */
2298 /* Destroy the execution state */
2300 }
2302 /*
2303 * postgresIsForeignRelUpdatable
2304 * Determine whether a foreign table supports INSERT, UPDATE and/or
2305 * DELETE.
2306 */
2307 static int
2309 {
2315 /*
2316 * By default, all postgres_fdw foreign tables are assumed updatable. This
2317 * can be overridden by a per-server setting, which in turn can be
2318 * overridden by a per-table setting.
2319 */
2326 {
2331 }
2333 {
2338 }
2340 /*
2341 * Currently "updatable" means support for INSERT, UPDATE and DELETE.
2342 */
2345 }
2347 /*
2348 * postgresRecheckForeignScan
2349 * Execute a local join execution plan for a foreign join
2350 */
2351 static bool
2353 {
2358 /* For base foreign relations, it suffices to set fdw_recheck_quals */
2364 /* Execute a local join execution plan */
2369 /* Store result in the given slot */
2373 }
2375 /*
2376 * find_modifytable_subplan
2377 * Helper routine for postgresPlanDirectModify to find the
2378 * ModifyTable subplan node that scans the specified RTI.
2379 *
2380 * Returns NULL if the subplan couldn't be identified. That's not a fatal
2381 * error condition, we just abandon trying to do the update directly.
2382 */
2386 Index rtindex,
2388 {
2391 /*
2392 * The cases we support are (1) the desired ForeignScan is the immediate
2393 * child of ModifyTable, or (2) it is the subplan_index'th child of an
2394 * Append node that is the immediate child of ModifyTable. There is no
2395 * point in looking further down, as that would mean that local joins are
2396 * involved, so we can't do the update directly.
2397 *
2398 * There could be a Result atop the Append too, acting to compute the
2399 * UPDATE targetlist values. We ignore that here; the tlist will be
2400 * checked by our caller.
2401 *
2402 * In principle we could examine all the children of the Append, but it's
2403 * currently unlikely that the core planner would generate such a plan
2404 * with the children out-of-order. Moreover, such a search risks costing
2405 * O(N^2) time when there are a lot of children.
2406 */
2408 {
2413 }
2417 {
2422 }
2424 /* Now, have we got a ForeignScan on the desired rel? */
2426 {
2431 }
2434 }
2436 /*
2437 * postgresPlanDirectModify
2438 * Consider a direct foreign table modification
2439 *
2440 * Decide whether it is safe to modify a foreign table directly, and if so,
2441 * rewrite subplan accordingly.
2442 */
2443 static bool
2446 Index resultRelation,
2448 {
2453 Relation rel;
2454 StringInfoData sql;
2463 /*
2464 * Decide whether it is safe to modify a foreign table directly.
2465 */
2467 /*
2468 * The table modification must be an UPDATE or DELETE.
2469 */
2473 /*
2474 * Try to locate the ForeignScan subplan that's scanning resultRelation.
2475 */
2480 /*
2481 * It's unsafe to modify a foreign table directly if there are any quals
2482 * that should be evaluated locally.
2483 */
2487 /* Safe to fetch data about the target foreign rel */
2489 {
2491 /* We should have a rel for this foreign join. */
2493 }
2494 else
2499 /*
2500 * It's unsafe to update a foreign table directly, if any expressions to
2501 * assign to the target columns are unsafe to evaluate remotely.
2502 */
2504 {
2508 /*
2509 * The expressions of concern are the first N columns of the processed
2510 * targetlist, where N is the length of the rel's update_colnos.
2511 */
2515 {
2519 /* update's new-value expressions shouldn't be resjunk */
2527 }
2528 }
2530 /*
2531 * Ok, rewrite subplan so as to modify the foreign table directly.
2532 */
2535 /*
2536 * Core code already has some lock on each rel being planned, so we can
2537 * use NoLock here.
2538 */
2541 /*
2542 * Recall the qual clauses that must be evaluated remotely. (These are
2543 * bare clauses not RestrictInfos, but deparse.c's appendConditions()
2544 * doesn't care.)
2545 */
2548 /*
2549 * Extract the relevant RETURNING list if any.
2550 */
2552 {
2555 /*
2556 * When performing an UPDATE/DELETE .. RETURNING on a join directly,
2557 * we fetch from the foreign server any Vars specified in RETURNING
2558 * that refer not only to the target relation but to non-target
2559 * relations. So we'll deparse them into the RETURNING clause of the
2560 * remote query; use a targetlist consisting of them instead, which
2561 * will be adjusted to be new fdw_scan_tlist of the foreign-scan plan
2562 * node below.
2563 */
2566 returningList);
2567 }
2569 /*
2570 * Construct the SQL command string.
2571 */
2573 {
2576 foreignrel,
2577 processed_tlist,
2578 targetAttrs,
2584 foreignrel,
2591 }
2593 /*
2594 * Update the operation and target relation info.
2595 */
2599 /*
2600 * Update the fdw_exprs list that will be available to the executor.
2601 */
2604 /*
2605 * Update the fdw_private list that will be available to the executor.
2606 * Items in the list must match enum FdwDirectModifyPrivateIndex, above.
2607 */
2610 retrieved_attrs,
2613 /*
2614 * Update the foreign-join-related fields.
2615 */
2617 {
2618 /* No need for the outer subplan. */
2621 /* Build new fdw_scan_tlist if UPDATE/DELETE .. RETURNING. */
2624 }
2626 /*
2627 * Finally, unset the async-capable flag if it is set, as we currently
2628 * don't support asynchronous execution of direct modifications.
2629 */
2635 }
2637 /*
2638 * postgresBeginDirectModify
2639 * Prepare a direct foreign table modification
2640 */
2641 static void
2643 {
2647 Index rtindex;
2648 Oid userid;
2653 /*
2654 * Do nothing in EXPLAIN (no ANALYZE) case. node->fdw_state stays NULL.
2655 */
2659 /*
2660 * We'll save private state in node->fdw_state.
2661 */
2665 /*
2666 * Identify which user to do the remote access as. This should match what
2667 * ExecCheckPermissions() does.
2668 */
2671 /* Get info about foreign table. */
2675 else
2680 /*
2681 * Get connection to the foreign server. Connection manager will
2682 * establish new connection if necessary.
2683 */
2686 /* Update the foreign-join-related fields. */
2688 {
2689 /* Save info about foreign table. */
2692 /*
2693 * Set dmstate->rel to NULL to teach get_returning_data() and
2694 * make_tuple_from_result_row() that columns fetched from the remote
2695 * server are described by fdw_scan_tlist of the foreign-scan plan
2696 * node, not the tuple descriptor for the target relation.
2697 */
2699 }
2701 /* Initialize state variable */
2704 /* Get private info created by planner functions. */
2706 FdwDirectModifyPrivateUpdateSql));
2708 FdwDirectModifyPrivateHasReturning));
2710 FdwDirectModifyPrivateRetrievedAttrs);
2712 FdwDirectModifyPrivateSetProcessed));
2714 /* Create context for per-tuple temp workspace. */
2717 ALLOCSET_SMALL_SIZES);
2719 /* Prepare for input conversion of RETURNING results. */
2721 {
2722 TupleDesc tupdesc;
2726 else
2731 /*
2732 * When performing an UPDATE/DELETE .. RETURNING on a join directly,
2733 * initialize a filter to extract an updated/deleted tuple from a scan
2734 * tuple.
2735 */
2738 }
2740 /*
2741 * Prepare for processing of parameters used in remote query, if any.
2742 */
2748 numParams,
2752 }
2754 /*
2755 * postgresIterateDirectModify
2756 * Execute a direct foreign table modification
2757 */
2760 {
2765 /*
2766 * If this is the first call after Begin, execute the statement.
2767 */
2771 /*
2772 * If the local query doesn't specify RETURNING, just clear tuple slot.
2773 */
2775 {
2781 /* Increment the command es_processed count if necessary. */
2785 /* Increment the tuple count for EXPLAIN ANALYZE if necessary. */
2790 }
2792 /*
2793 * Get the next RETURNING tuple.
2794 */
2796 }
2798 /*
2799 * postgresEndDirectModify
2800 * Finish a direct foreign table modification
2801 */
2802 static void
2804 {
2807 /* if dmstate is NULL, we are in EXPLAIN; nothing to do */
2811 /* Release PGresult */
2814 /* Release remote connection */
2818 /* MemoryContext will be deleted automatically. */
2819 }
2821 /*
2822 * postgresExplainForeignScan
2823 * Produce extra output for EXPLAIN of a ForeignScan on a foreign table
2824 */
2825 static void
2827 {
2831 /*
2832 * Identify foreign scans that are really joins or upper relations. The
2833 * input looks something like "(1) LEFT JOIN (2)", and we must replace the
2834 * digit string(s), which are RT indexes, with the correct relation names.
2835 * We do that here, not when the plan is created, because we can't know
2836 * what aliases ruleutils.c will assign at plan creation time.
2837 */
2839 {
2840 StringInfo relations;
2844 rtoffset;
2848 /*
2849 * A difficulty with using a string representation of RT indexes is
2850 * that setrefs.c won't update the string when flattening the
2851 * rangetable. To find out what rtoffset was applied, identify the
2852 * minimum RT index appearing in the string and compare it to the
2853 * minimum member of plan->fs_base_relids. (We expect all the relids
2854 * in the join will have been offset by the same amount; the Asserts
2855 * below should catch it if that ever changes.)
2856 */
2860 {
2862 {
2867 }
2868 else
2869 ptr++;
2870 }
2873 /* Now we can translate the string */
2877 {
2879 {
2889 /* This logic should agree with explain.c's ExplainTargetRel */
2892 {
2899 }
2900 else
2909 }
2910 else
2912 }
2914 }
2916 /*
2917 * Add remote query, when VERBOSE option is specified.
2918 */
2920 {
2925 }
2926 }
2928 /*
2929 * postgresExplainForeignModify
2930 * Produce extra output for EXPLAIN of a ModifyTable on a foreign table
2931 */
2932 static void
2938 {
2940 {
2942 FdwModifyPrivateUpdateSql));
2946 /*
2947 * For INSERT we should always have batch size >= 1, but UPDATE and
2948 * DELETE don't support batching so don't show the property.
2949 */
2952 }
2953 }
2955 /*
2956 * postgresExplainDirectModify
2957 * Produce extra output for EXPLAIN of a ForeignScan that modifies a
2958 * foreign table directly
2959 */
2960 static void
2962 {
2967 {
2971 }
2972 }
2974 /*
2975 * postgresExecForeignTruncate
2976 * Truncate one or more foreign tables
2977 */
2978 static void
2980 DropBehavior behavior,
2982 {
2986 StringInfoData sql;
2990 /*
2991 * By default, all postgres_fdw foreign tables are assumed truncatable.
2992 * This can be overridden by a per-server setting, which in turn can be
2993 * overridden by a per-table setting.
2994 */
2996 {
3003 /*
3004 * First time through, determine whether the foreign server allows
3005 * truncates. Since all specified foreign tables are assumed to belong
3006 * to the same foreign server, this result can be used for other
3007 * foreign tables.
3008 */
3010 {
3015 {
3019 {
3022 }
3023 }
3024 }
3026 /*
3027 * Confirm that all specified foreign tables belong to the same
3028 * foreign server.
3029 */
3032 /* Determine whether this foreign table allows truncations */
3035 {
3039 {
3042 }
3043 }
3050 }
3053 /*
3054 * Get connection to the foreign server. Connection manager will
3055 * establish new connection if necessary.
3056 */
3060 /* Construct the TRUNCATE command string */
3064 /* Issue the TRUNCATE command to remote server */
3068 }
3070 /*
3071 * estimate_path_cost_size
3072 * Get cost and size estimates for a foreign scan on given foreign relation
3073 * either a base relation or a join between foreign relations or an upper
3074 * relation containing foreign relations.
3075 *
3076 * param_join_conds are the parameterization clauses with outer relations.
3077 * pathkeys specify the expected sort order if any for given path being costed.
3078 * fpextra specifies additional post-scan/join-processing steps such as the
3079 * final sort and the LIMIT restriction.
3080 *
3081 * The function returns the cost and size estimates in p_rows, p_width,
3082 * p_startup_cost and p_total_cost variables.
3083 */
3084 static void
3092 {
3097 Cost startup_cost;
3098 Cost total_cost;
3100 /* Make sure the core code has set up the relation's reltarget */
3103 /*
3104 * If the table or the server is configured to use remote estimates,
3105 * connect to the foreign server and execute EXPLAIN to estimate the
3106 * number of rows selected by the restriction+join clauses. Otherwise,
3107 * estimate rows using whatever statistics we have locally, in a way
3108 * similar to ordinary tables.
3109 */
3111 {
3114 StringInfoData sql;
3116 Selectivity local_sel;
3117 QualCost local_cost;
3121 /* Required only to be passed to deparseSelectStmtForRel */
3124 /*
3125 * param_join_conds might contain both clauses that are safe to send
3126 * across, and clauses that aren't.
3127 */
3131 /* Build the list of columns to be fetched from the foreign server. */
3134 else
3137 /*
3138 * The complete list of remote conditions includes everything from
3139 * baserestrictinfo plus any extra join_conds relevant to this
3140 * particular path.
3141 */
3145 /*
3146 * Construct EXPLAIN query including the desired SELECT, FROM, and
3147 * WHERE clauses. Params and other-relation Vars are replaced by dummy
3148 * values, so don't request params_list.
3149 */
3158 /* Get the remote estimate */
3166 /* Factor in the selectivity of the locally-checked quals */
3168 local_param_join_conds,
3170 JOIN_INNER,
3171 NULL);
3176 /* Add in the eval cost of the locally-checked quals */
3183 /*
3184 * Add in tlist eval cost for each output row. In case of an
3185 * aggregate, some of the tlist expressions such as grouping
3186 * expressions will be evaluated remotely, so adjust the costs.
3187 */
3192 {
3193 QualCost tlist_cost;
3199 }
3200 }
3201 else
3202 {
3205 /*
3206 * We don't support join conditions in this mode (hence, no
3207 * parameterized paths can be made).
3208 */
3211 /*
3212 * We will come here again and again with different set of pathkeys or
3213 * additional post-scan/join-processing steps that caller wants to
3214 * cost. We don't need to calculate the cost/size estimates for the
3215 * underlying scan, join, or grouping each time. Instead, use those
3216 * estimates if we have cached them already.
3217 */
3219 {
3228 /*
3229 * If we estimate the costs of a foreign scan or a foreign join
3230 * with additional post-scan/join-processing steps, the scan or
3231 * join costs obtained from the cache wouldn't yet contain the
3232 * eval costs for the final scan/join target, which would've been
3233 * updated by apply_scanjoin_target_to_paths(); add the eval costs
3234 * now.
3235 */
3237 {
3238 /* Shouldn't get here unless we have LIMIT */
3244 }
3245 }
3247 {
3250 QualCost join_cost;
3251 QualCost remote_conds_cost;
3254 /* Use rows/width estimates made by the core code. */
3258 /* For join we expect inner and outer relations set */
3264 /* Estimate of number of rows in cross product */
3267 /*
3268 * Back into an estimate of the number of retrieved rows. Just in
3269 * case this is nuts, clamp to at most nrows.
3270 */
3274 /*
3275 * The cost of foreign join is estimated as cost of generating
3276 * rows for the joining relations + cost for applying quals on the
3277 * rows.
3278 */
3280 /*
3281 * Calculate the cost of clauses pushed down to the foreign server
3282 */
3284 /* Calculate the cost of applying join clauses */
3287 /*
3288 * Startup cost includes startup cost of joining relations and the
3289 * startup cost for join and other clauses. We do not include the
3290 * startup cost specific to join strategy (e.g. setting up hash
3291 * tables) since we do not know what strategy the foreign server
3292 * is going to use.
3293 */
3299 /*
3300 * Run time cost includes:
3301 *
3302 * 1. Run time cost (total_cost - startup_cost) of relations being
3303 * joined
3304 *
3305 * 2. Run time cost of applying join clauses on the cross product
3306 * of the joining relations.
3307 *
3308 * 3. Run time cost of applying pushed down other clauses on the
3309 * result of join
3310 *
3311 * 4. Run time cost of applying nonpushable other clauses locally
3312 * on the result fetched from the foreign server.
3313 */
3321 /* Add in tlist eval cost for each output row */
3324 }
3326 {
3329 AggClauseCosts aggcosts;
3334 /* The upper relation should have its outer relation set */
3336 /* and that outer relation should have its reltarget set */
3339 /*
3340 * This cost model is mixture of costing done for sorted and
3341 * hashed aggregates in cost_agg(). We are not sure which
3342 * strategy will be considered at remote side, thus for
3343 * simplicity, we put all startup related costs in startup_cost
3344 * and all finalization and run cost are added in total_cost.
3345 */
3349 /* Get rows from input rel */
3352 /* Collect statistics about aggregates for estimating costs. */
3355 {
3357 }
3359 /* Get number of grouping columns and possible number of groups */
3366 /*
3367 * Get the retrieved_rows and rows estimates. If there are HAVING
3368 * quals, account for their selectivity.
3369 */
3371 {
3372 /* Factor in the selectivity of the remotely-checked quals */
3373 retrieved_rows =
3378 JOIN_INNER,
3379 NULL));
3380 /* Factor in the selectivity of the locally-checked quals */
3382 }
3383 else
3384 {
3386 }
3388 /* Use width estimate made by the core code. */
3391 /*-----
3392 * Startup cost includes:
3393 * 1. Startup cost for underneath input relation, adjusted for
3394 * tlist replacement by apply_scanjoin_target_to_paths()
3395 * 2. Cost of performing aggregation, per cost_agg()
3396 *-----
3397 */
3405 /*-----
3406 * Run time cost includes:
3407 * 1. Run time cost of underneath input relation, adjusted for
3408 * tlist replacement by apply_scanjoin_target_to_paths()
3409 * 2. Run time cost of performing aggregation, per cost_agg()
3410 *-----
3411 */
3417 /* Account for the eval cost of HAVING quals, if any */
3419 {
3420 QualCost remote_cost;
3422 /* Add in the eval cost of the remotely-checked quals */
3426 /* Add in the eval cost of the locally-checked quals */
3429 }
3431 /* Add in tlist eval cost for each output row */
3434 }
3435 else
3436 {
3437 Cost cpu_per_tuple;
3439 /* Use rows/width estimates made by set_baserel_size_estimates. */
3443 /*
3444 * Back into an estimate of the number of retrieved rows. Just in
3445 * case this is nuts, clamp to at most foreignrel->tuples.
3446 */
3450 /*
3451 * Cost as though this were a seqscan, which is pessimistic. We
3452 * effectively imagine the local_conds are being evaluated
3453 * remotely, too.
3454 */
3463 /* Add in tlist eval cost for each output row */
3466 }
3468 /*
3469 * Without remote estimates, we have no real way to estimate the cost
3470 * of generating sorted output. It could be free if the query plan
3471 * the remote side would have chosen generates properly-sorted output
3472 * anyway, but in most cases it will cost something. Estimate a value
3473 * high enough that we won't pick the sorted path when the ordering
3474 * isn't locally useful, but low enough that we'll err on the side of
3475 * pushing down the ORDER BY clause when it's useful to do so.
3476 */
3478 {
3480 {
3487 }
3488 else
3489 {
3492 }
3493 }
3497 /* Adjust the cost estimates if we have LIMIT */
3499 {
3503 }
3504 }
3506 /*
3507 * If this includes the final sort step, the given target, which will be
3508 * applied to the resulting path, might have different expressions from
3509 * the foreignrel's reltarget (see make_sort_input_target()); adjust tlist
3510 * eval costs.
3511 */
3514 {
3521 }
3523 /*
3524 * Cache the retrieved rows and cost estimates for scans, joins, or
3525 * groupings without any parameterization, pathkeys, or additional
3526 * post-scan/join-processing steps, before adding the costs for
3527 * transferring data from the foreign server. These estimates are useful
3528 * for costing remote joins involving this relation or costing other
3529 * remote operations on this relation such as remote sorts and remote
3530 * LIMIT restrictions, when the costs can not be obtained from the foreign
3531 * server. This function will be called at least once for every foreign
3532 * relation without any parameterization, pathkeys, or additional
3533 * post-scan/join-processing steps.
3534 */
3536 {
3540 }
3542 /*
3543 * Add some additional cost factors to account for connection overhead
3544 * (fdw_startup_cost), transferring data across the network
3545 * (fdw_tuple_cost per retrieved row), and local manipulation of the data
3546 * (cpu_tuple_cost per retrieved row).
3547 */
3553 /*
3554 * If we have LIMIT, we should prefer performing the restriction remotely
3555 * rather than locally, as the former avoids extra row fetches from the
3556 * remote that the latter might cause. But since the core code doesn't
3557 * account for such fetches when estimating the costs of the local
3558 * restriction (see create_limit_path()), there would be no difference
3559 * between the costs of the local restriction and the costs of the remote
3560 * restriction estimated above if we don't use remote estimates (except
3561 * for the case where the foreignrel is a grouping relation, the given
3562 * pathkeys is not NIL, and the effects of a bounded sort for that rel is
3563 * accounted for in costing the remote restriction). Tweak the costs of
3564 * the remote restriction to ensure we'll prefer it if LIMIT is a useful
3565 * one.
3566 */
3571 {
3575 }
3577 /* Return results. */
3582 }
3584 /*
3585 * Estimate costs of executing a SQL statement remotely.
3586 * The given "sql" must be an EXPLAIN command.
3587 */
3588 static void
3592 {
3595 /* PGresult must be released before leaving this function. */
3597 {
3602 /*
3603 * Execute EXPLAIN remotely.
3604 */
3609 /*
3610 * Extract cost numbers for topmost plan node. Note we search for a
3611 * left paren from the end of the line to avoid being confused by
3612 * other uses of parentheses.
3613 */
3622 }
3624 {
3626 }
3628 }
3630 /*
3631 * Adjust the cost estimates of a foreign grouping path to include the cost of
3632 * generating properly-sorted output.
3633 */
3634 static void
3642 {
3643 /*
3644 * If the GROUP BY clause isn't sort-able, the plan chosen by the remote
3645 * side is unlikely to generate properly-sorted output, so it would need
3646 * an explicit sort; adjust the given costs with cost_sort(). Likewise,
3647 * if the GROUP BY clause is sort-able but isn't a superset of the given
3648 * pathkeys, adjust the costs with that function. Otherwise, adjust the
3649 * costs by applying the same heuristic as for the scan or join case.
3650 */
3653 {
3657 root,
3658 pathkeys,
3660 retrieved_rows,
3661 width,
3663 work_mem,
3664 limit_tuples);
3668 }
3669 else
3670 {
3671 /*
3672 * The default extra cost seems too large for foreign-grouping cases;
3673 * add 1/4th of that default.
3674 */
3680 }
3681 }
3683 /*
3684 * Detect whether we want to process an EquivalenceClass member.
3685 *
3686 * This is a callback for use by generate_implied_equalities_for_column.
3687 */
3688 static bool
3692 {
3696 /*
3697 * If we've identified what we're processing in the current scan, we only
3698 * want to match that expression.
3699 */
3703 /*
3704 * Otherwise, ignore anything we've already processed.
3705 */
3709 /* This is the new target to process. */
3712 }
3714 /*
3715 * Create cursor for node's query with current parameter values.
3716 */
3717 static void
3719 {
3725 StringInfoData buf;
3728 /* First, process a pending asynchronous request, if any. */
3732 /*
3733 * Construct array of query parameter values in text format. We do the
3734 * conversions in the short-lived per-tuple context, so as not to cause a
3735 * memory leak over repeated scans.
3736 */
3738 {
3739 MemoryContext oldcontext;
3746 values);
3749 }
3751 /* Construct the DECLARE CURSOR command */
3756 /*
3757 * Notice that we pass NULL for paramTypes, thus forcing the remote server
3758 * to infer types for all parameters. Since we explicitly cast every
3759 * parameter (see deparse.c), the "inference" is trivial and will produce
3760 * the desired result. This allows us to avoid assuming that the remote
3761 * server has the same OIDs we do for the parameters' types.
3762 */
3767 /*
3768 * Get the result, and check for success.
3769 *
3770 * We don't use a PG_TRY block here, so be careful not to throw error
3771 * without releasing the PGresult.
3772 */
3778 /* Mark the cursor as created, and show no tuples have been retrieved */
3786 /* Clean up */
3788 }
3790 /*
3791 * Fetch some more rows from the node's cursor.
3792 */
3793 static void
3795 {
3798 MemoryContext oldcontext;
3800 /*
3801 * We'll store the tuples in the batch_cxt. First, flush the previous
3802 * batch.
3803 */
3808 /* PGresult must be released before leaving this function. */
3810 {
3816 {
3819 /*
3820 * The query was already sent by an earlier call to
3821 * fetch_more_data_begin. So now we just fetch the result.
3822 */
3824 /* On error, report the original query, not the FETCH. */
3828 /* Reset per-connection state */
3830 }
3831 else
3832 {
3835 /* This is a regular synchronous fetch. */
3840 /* On error, report the original query, not the FETCH. */
3843 }
3845 /* Convert the data into HeapTuples */
3852 {
3860 node,
3862 }
3864 /* Update fetch_ct_2 */
3868 /* Must be EOF if we didn't get as many tuples as we asked for. */
3870 }
3872 {
3874 }
3878 }
3880 /*
3881 * Force assorted GUC parameters to settings that ensure that we'll output
3882 * data values in a form that is unambiguous to the remote server.
3883 *
3884 * This is rather expensive and annoying to do once per row, but there's
3885 * little choice if we want to be sure values are transmitted accurately;
3886 * we can't leave the settings in place between rows for fear of affecting
3887 * user-visible computations.
3888 *
3889 * We use the equivalent of a function SET option to allow the settings to
3890 * persist only until the caller calls reset_transmission_modes(). If an
3891 * error is thrown in between, guc.c will take care of undoing the settings.
3892 *
3893 * The return value is the nestlevel that must be passed to
3894 * reset_transmission_modes() to undo things.
3895 */
3896 int
3898 {
3901 /*
3902 * The values set here should match what pg_dump does. See also
3903 * configure_remote_session in connection.c.
3904 */
3918 /*
3919 * In addition force restrictive search_path, in case there are any
3920 * regproc or similar constants to be printed.
3921 */
3927 }
3929 /*
3930 * Undo the effects of set_transmission_modes().
3931 */
3932 void
3934 {
3936 }
3938 /*
3939 * Utility routine to close a cursor.
3940 */
3941 static void
3944 {
3950 /*
3951 * We don't use a PG_TRY block here, so be careful not to throw error
3952 * without releasing the PGresult.
3953 */
3958 }
3960 /*
3961 * create_foreign_modify
3962 * Construct an execution state of a foreign insert/update/delete
3963 * operation
3964 */
3969 CmdType operation,
3976 {
3980 Oid userid;
3983 AttrNumber n_params;
3984 Oid typefnoid;
3988 /* Begin constructing PgFdwModifyState. */
3992 /* Identify which user to do the remote access as. */
3995 /* Get info about foreign table. */
3999 /* Open connection; report that we'll create a prepared statement. */
4003 /* Set up remote query information. */
4006 {
4009 }
4015 /* Create context for per-tuple temp workspace. */
4018 ALLOCSET_SMALL_SIZES);
4020 /* Prepare for input conversion of RETURNING results. */
4024 /* Prepare for output conversion of parameters used in prepared stmt. */
4030 {
4033 /* Find the ctid resjunk column in the subplan's result */
4039 /* First transmittable parameter will be ctid */
4043 }
4046 {
4047 /* Set up for remaining transmittable parameters */
4049 {
4055 /* Ignore generated columns; they are set to DEFAULT */
4061 }
4062 }
4066 /* Set batch_size from foreign server/table options. */
4072 /* Initialize auxiliary state */
4076 }
4078 /*
4079 * execute_foreign_modify
4080 * Perform foreign-table modification as required, and fetch RETURNING
4081 * result if any. (This is the shared guts of postgresExecForeignInsert,
4082 * postgresExecForeignBatchInsert, postgresExecForeignUpdate, and
4083 * postgresExecForeignDelete.)
4084 */
4088 CmdType operation,
4092 {
4098 StringInfoData sql;
4100 /* The operation should be INSERT, UPDATE, or DELETE */
4105 /* First, process a pending asynchronous request, if any. */
4109 /*
4110 * If the existing query was deparsed and prepared for a different number
4111 * of rows, rebuild it for the proper number.
4112 */
4114 {
4115 /* Destroy the prepared statement created previously */
4119 /* Build INSERT string with numSlots records in its VALUES clause. */
4128 }
4130 /* Set up the prepared statement on the remote server, if we didn't yet */
4134 /*
4135 * For UPDATE/DELETE, get the ctid that was passed up as a resjunk column
4136 */
4138 {
4139 Datum datum;
4145 /* shouldn't ever get a null result... */
4149 }
4151 /* Convert parameters needed by prepared statement to text form */
4154 /*
4155 * Execute the prepared statement.
4156 */
4160 p_values,
4161 NULL,
4162 NULL,
4166 /*
4167 * Get the result, and check for success.
4168 *
4169 * We don't use a PG_TRY block here, so be careful not to throw error
4170 * without releasing the PGresult.
4171 */
4177 /* Check number of rows affected, and fetch RETURNING tuple if any */
4179 {
4184 }
4185 else
4188 /* And clean up */
4195 /*
4196 * Return NULL if nothing was inserted/updated/deleted on the remote end
4197 */
4199 }
4201 /*
4202 * prepare_foreign_modify
4203 * Establish a prepared statement for execution of INSERT/UPDATE/DELETE
4204 */
4205 static void
4207 {
4212 /*
4213 * The caller would already have processed a pending asynchronous request
4214 * if any, so no need to do it here.
4215 */
4217 /* Construct name we'll use for the prepared statement. */
4222 /*
4223 * We intentionally do not specify parameter types here, but leave the
4224 * remote server to derive them by default. This avoids possible problems
4225 * with the remote server using different type OIDs than we do. All of
4226 * the prepared statements we use in this module are simple enough that
4227 * the remote server will make the right choices.
4228 */
4230 p_name,
4233 NULL))
4236 /*
4237 * Get the result, and check for success.
4238 *
4239 * We don't use a PG_TRY block here, so be careful not to throw error
4240 * without releasing the PGresult.
4241 */
4247 /* This action shows that the prepare has been done. */
4249 }
4251 /*
4252 * convert_prep_stmt_params
4253 * Create array of text strings representing parameter values
4254 *
4255 * tupleid is ctid to send, or NULL if none
4256 * slot is slot to get remaining parameters from, or NULL if none
4257 *
4258 * Data is constructed in temp_cxt; caller should reset that after use.
4259 */
4262 ItemPointer tupleid,
4265 {
4270 MemoryContext oldcontext;
4276 /* ctid is provided only for UPDATE/DELETE, which don't allow batching */
4279 /* 1st parameter should be ctid, if it's in use */
4281 {
4283 /* don't need set_transmission_modes for TID output */
4286 pindex++;
4287 }
4289 /* get following parameters from slots */
4291 {
4299 {
4302 {
4305 Datum value;
4308 /* Ignore generated columns; they are set to DEFAULT */
4314 else
4316 value);
4317 pindex++;
4318 j++;
4319 }
4320 }
4323 }
4330 }
4332 /*
4333 * store_returning_result
4334 * Store the result of a RETURNING clause
4335 *
4336 * On error, be sure to release the PGresult on the way out. Callers do not
4337 * have PG_TRY blocks to ensure this happens.
4338 */
4339 static void
4342 {
4344 {
4345 HeapTuple newtup;
4351 NULL,
4354 /*
4355 * The returning slot will not necessarily be suitable to store
4356 * heaptuples directly, so allow for conversion.
4357 */
4359 }
4361 {
4364 }
4366 }
4368 /*
4369 * finish_foreign_modify
4370 * Release resources for a foreign insert/update/delete operation
4371 */
4372 static void
4374 {
4377 /* If we created a prepared statement, destroy it */
4380 /* Release remote connection */
4383 }
4385 /*
4386 * deallocate_query
4387 * Deallocate a prepared statement for a foreign insert/update/delete
4388 * operation
4389 */
4390 static void
4392 {
4396 /* do nothing if the query is not allocated */
4402 /*
4403 * We don't use a PG_TRY block here, so be careful not to throw error
4404 * without releasing the PGresult.
4405 */
4412 }
4414 /*
4415 * build_remote_returning
4416 * Build a RETURNING targetlist of a remote query for performing an
4417 * UPDATE/DELETE .. RETURNING on a join directly
4418 */
4421 {
4431 /*
4432 * If there's a whole-row reference to the target relation, then we'll
4433 * need all the columns of the relation.
4434 */
4436 {
4442 {
4445 }
4446 }
4449 {
4454 {
4458 /* Ignore dropped attributes. */
4463 i,
4472 NULL,
4474 }
4475 }
4477 /* Now add any remaining columns to tlist. */
4479 {
4482 /*
4483 * No need for whole-row references to the target relation. We don't
4484 * need system columns other than ctid and oid either, since those are
4485 * set locally.
4486 */
4499 NULL,
4501 }
4506 }
4508 /*
4509 * rebuild_fdw_scan_tlist
4510 * Build new fdw_scan_tlist of given foreign-scan plan node from given
4511 * tlist
4512 *
4513 * There might be columns that the fdw_scan_tlist of the given foreign-scan
4514 * plan node contains that the given tlist doesn't. The fdw_scan_tlist would
4515 * have contained resjunk columns such as 'ctid' of the target relation and
4516 * 'wholerow' of non-target relations, but the tlist might not contain them,
4517 * for example. So, adjust the tlist so it contains all the columns specified
4518 * in the fdw_scan_tlist; else setrefs.c will get confused.
4519 */
4520 static void
4522 {
4528 {
4537 NULL,
4539 }
4541 }
4543 /*
4544 * Execute a direct UPDATE/DELETE statement.
4545 */
4546 static void
4548 {
4554 /* First, process a pending asynchronous request, if any. */
4558 /*
4559 * Construct array of query parameter values in text format.
4560 */
4565 values);
4567 /*
4568 * Notice that we pass NULL for paramTypes, thus forcing the remote server
4569 * to infer types for all parameters. Since we explicitly cast every
4570 * parameter (see deparse.c), the "inference" is trivial and will produce
4571 * the desired result. This allows us to avoid assuming that the remote
4572 * server has the same OIDs we do for the parameters' types.
4573 */
4578 /*
4579 * Get the result, and check for success.
4580 *
4581 * We don't use a PG_TRY block here, so be careful not to throw error
4582 * without releasing the PGresult.
4583 */
4590 /* Get the number of rows affected. */
4593 else
4595 }
4597 /*
4598 * Get the result of a RETURNING clause.
4599 */
4602 {
4611 /* If we didn't get any tuples, must be end of data. */
4615 /* Increment the command es_processed count if necessary. */
4619 /*
4620 * Store a RETURNING tuple. If has_returning is false, just emit a dummy
4621 * tuple. (has_returning is false when the local query is of the form
4622 * "UPDATE/DELETE .. RETURNING 1" for example.)
4623 */
4625 {
4628 }
4629 else
4630 {
4631 /*
4632 * On error, be sure to release the PGresult on the way out. Callers
4633 * do not have PG_TRY blocks to ensure this happens.
4634 */
4636 {
4637 HeapTuple newtup;
4644 node,
4647 }
4649 {
4652 }
4655 /* Get the updated/deleted tuple. */
4658 else
4660 }
4663 /* Make slot available for evaluation of the local query RETURNING list. */
4665 resultSlot;
4668 }
4670 /*
4671 * Initialize a filter to extract an updated/deleted tuple from a scan tuple.
4672 */
4673 static void
4676 Index rtindex)
4677 {
4682 /*
4683 * Calculate the mapping between the fdw_scan_tlist's entries and the
4684 * result tuple's attributes.
4685 *
4686 * The "map" is an array of indexes of the result tuple's attributes in
4687 * fdw_scan_tlist, i.e., one entry for every attribute of the result
4688 * tuple. We store zero for any attributes that don't have the
4689 * corresponding entries in that list, marking that a NULL is needed in
4690 * the result tuple.
4691 *
4692 * Also get the indexes of the entries for ctid and oid if any.
4693 */
4702 {
4708 /*
4709 * If the Var is a column of the target relation to be retrieved from
4710 * the foreign server, get the index of the entry.
4711 */
4714 {
4718 {
4719 /*
4720 * We don't retrieve system columns other than ctid and oid.
4721 */
4724 else
4727 }
4728 else
4729 {
4730 /*
4731 * We don't retrieve whole-row references to the target
4732 * relation either.
4733 */
4737 }
4738 }
4739 i++;
4740 }
4741 }
4743 /*
4744 * Extract and return an updated/deleted tuple from a scan tuple.
4745 */
4751 {
4760 /*
4761 * Use the return tuple slot as a place to store the result tuple.
4762 */
4765 /*
4766 * Extract all the values of the scan tuple.
4767 */
4772 /*
4773 * Prepare to build the result tuple.
4774 */
4779 /*
4780 * Transpose data into proper fields of the result tuple.
4781 */
4783 {
4787 {
4790 }
4791 else
4792 {
4795 }
4796 }
4798 /*
4799 * Build the virtual tuple.
4800 */
4803 /*
4804 * If we have any system columns to return, materialize a heap tuple in
4805 * the slot from column values set above and install system columns in
4806 * that tuple.
4807 */
4809 {
4812 /* ctid */
4814 {
4819 }
4821 /*
4822 * And remaining columns
4823 *
4824 * Note: since we currently don't allow the target relation to appear
4825 * on the nullable side of an outer join, any system columns wouldn't
4826 * go to NULL.
4827 *
4828 * Note: no need to care about tableoid here because it will be
4829 * initialized in ExecProcessReturning().
4830 */
4834 }
4836 /*
4837 * And return the result tuple.
4838 */
4840 }
4842 /*
4843 * Prepare for processing of parameters used in remote query.
4844 */
4845 static void
4852 {
4858 /* Prepare for output conversion of parameters used in remote query. */
4863 {
4865 Oid typefnoid;
4870 i++;
4871 }
4873 /*
4874 * Prepare remote-parameter expressions for evaluation. (Note: in
4875 * practice, we expect that all these expressions will be just Params, so
4876 * we could possibly do something more efficient than using the full
4877 * expression-eval machinery for this. But probably there would be little
4878 * benefit, and it'd require postgres_fdw to know more than is desirable
4879 * about Param evaluation.)
4880 */
4883 /* Allocate buffer for text form of query parameters. */
4885 }
4887 /*
4888 * Construct array of query parameter values in text format.
4889 */
4890 static void
4895 {
4904 {
4906 Datum expr_value;
4909 /* Evaluate the parameter expression */
4912 /*
4913 * Get string representation of each parameter value by invoking
4914 * type-specific output function, unless the value is null.
4915 */
4918 else
4921 i++;
4922 }
4925 }
4927 /*
4928 * postgresAnalyzeForeignTable
4929 * Test whether analyzing this foreign table is supported
4930 */
4931 static bool
4935 {
4939 StringInfoData sql;
4942 /* Return the row-analysis function pointer */
4945 /*
4946 * Now we have to get the number of pages. It's annoying that the ANALYZE
4947 * API requires us to return that now, because it forces some duplication
4948 * of effort between this routine and postgresAcquireSampleRowsFunc. But
4949 * it's probably not worth redefining that API at this point.
4950 */
4952 /*
4953 * Get the connection to use. We do the remote access as the table's
4954 * owner, even if the ANALYZE was started by some other user.
4955 */
4960 /*
4961 * Construct command to get page count for relation.
4962 */
4966 /* In what follows, do not risk leaking any PGresults. */
4968 {
4976 }
4978 {
4980 }
4986 }
4988 /*
4989 * postgresGetAnalyzeInfoForForeignTable
4990 * Count tuples in foreign table (just get pg_class.reltuples).
4991 *
4992 * can_tablesample determines if the remote relation supports acquiring the
4993 * sample using TABLESAMPLE.
4994 */
4995 static double
4997 {
5001 StringInfoData sql;
5006 /* assume the remote relation does not support TABLESAMPLE */
5009 /*
5010 * Get the connection to use. We do the remote access as the table's
5011 * owner, even if the ANALYZE was started by some other user.
5012 */
5017 /*
5018 * Construct command to get page count for relation.
5019 */
5023 /* In what follows, do not risk leaking any PGresults. */
5025 {
5034 }
5036 {
5039 }
5044 /* TABLESAMPLE is supported only for regular tables and matviews */
5050 }
5052 /*
5053 * Acquire a random sample of rows from foreign table managed by postgres_fdw.
5054 *
5055 * Selected rows are returned in the caller-allocated array rows[],
5056 * which must have at least targrows entries.
5057 * The actual number of rows selected is returned as the function result.
5058 * We also count the total number of rows in the table and return it into
5059 * *totalrows. Note that *totaldeadrows is always set to 0.
5060 *
5061 * Note that the returned list of rows is not always in order by physical
5062 * position in the table. Therefore, correlation estimates derived later
5063 * may be meaningless, but it's OK because we don't use the estimates
5064 * currently (the planner only pays attention to correlation for indexscans).
5065 */
5066 static int
5071 {
5072 PgFdwAnalyzeState astate;
5082 StringInfoData sql;
5086 /* Initialize workspace state */
5097 /* Remember ANALYZE context, and create a per-tuple temp context */
5101 ALLOCSET_SMALL_SIZES);
5103 /*
5104 * Get the connection to use. We do the remote access as the table's
5105 * owner, even if the ANALYZE was started by some other user.
5106 */
5112 /* We'll need server version, so fetch it now. */
5115 /*
5116 * What sampling method should we use?
5117 */
5119 {
5123 {
5138 }
5139 }
5142 {
5146 {
5161 }
5162 }
5164 /*
5165 * Error-out if explicitly required one of the TABLESAMPLE methods, but
5166 * the server does not support it.
5167 */
5175 /*
5176 * If we've decided to do remote sampling, calculate the sampling rate. We
5177 * need to get the number of tuples from the remote server, but skip that
5178 * network round-trip if not needed.
5179 */
5181 {
5187 /*
5188 * Make sure we're not choosing TABLESAMPLE when the remote relation
5189 * does not support that. But only do this for "auto" - if the user
5190 * explicitly requested BERNOULLI/SYSTEM, it's better to fail.
5191 */
5195 /*
5196 * Remote's reltuples could be 0 or -1 if the table has never been
5197 * vacuumed/analyzed. In that case, disable sampling after all.
5198 */
5201 else
5202 {
5203 /*
5204 * All supported sampling methods require sampling rate, not
5205 * target rows directly, so we calculate that using the remote
5206 * reltuples value. That's imperfect, because it might be off a
5207 * good deal, but that's not something we can (or should) address
5208 * here.
5209 *
5210 * If reltuples is too low (i.e. when table grew), we'll end up
5211 * sampling more rows - but then we'll apply the local sampling,
5212 * so we get the expected sample size. This is the same outcome as
5213 * without remote sampling.
5214 *
5215 * If reltuples is too high (e.g. after bulk DELETE), we will end
5216 * up sampling too few rows.
5217 *
5218 * We can't really do much better here - we could try sampling a
5219 * bit more rows, but we don't know how off the reltuples value is
5220 * so how much is "a bit more"?
5221 *
5222 * Furthermore, the targrows value for partitions is determined
5223 * based on table size (relpages), which can be off in different
5224 * ways too. Adjusting the sampling rate here might make the issue
5225 * worse.
5226 */
5229 /*
5230 * We should never get sampling rate outside the valid range
5231 * (between 0.0 and 1.0), because those cases should be covered by
5232 * the previous branch that sets ANALYZE_SAMPLE_OFF.
5233 */
5235 }
5236 }
5238 /*
5239 * For "auto" method, pick the one we believe is best. For servers with
5240 * TABLESAMPLE support we pick BERNOULLI, for old servers we fall-back to
5241 * random() to at least reduce network transfer.
5242 */
5244 {
5247 else
5249 }
5251 /*
5252 * Construct cursor that retrieves whole rows from remote.
5253 */
5260 /* In what follows, do not risk leaking any PGresults. */
5262 {
5272 /*
5273 * Determine the fetch size. The default is arbitrary, but shouldn't
5274 * be enormous.
5275 */
5278 {
5282 {
5285 }
5286 }
5288 {
5292 {
5295 }
5296 }
5298 /* Construct command to fetch rows from remote. */
5302 /* Retrieve and process rows a batch at a time. */
5304 {
5308 /* Allow users to cancel long query */
5311 /*
5312 * XXX possible future improvement: if rowstoskip is large, we
5313 * could issue a MOVE rather than physically fetching the rows,
5314 * then just adjust rowstoskip and samplerows appropriately.
5315 */
5317 /* Fetch some rows */
5319 /* On error, report the original query, not the FETCH. */
5323 /* Process whatever we got. */
5331 /* Must be EOF if we didn't get all the rows requested. */
5334 }
5336 /* Close the cursor, just to be tidy. */
5338 }
5340 {
5343 }
5348 /* We assume that we have no dead tuple. */
5351 /*
5352 * Without sampling, we've retrieved all living tuples from foreign
5353 * server, so report that as totalrows. Otherwise use the reltuples
5354 * estimate we got from the remote side.
5355 */
5358 else
5361 /*
5362 * Emit some interesting relation info
5363 */
5370 }
5372 /*
5373 * Collect sample rows from the result of query.
5374 * - Use all tuples in sample until target # of samples are collected.
5375 * - Subsequently, replace already-sampled tuples randomly.
5376 */
5377 static void
5379 {
5382 MemoryContext oldcontext;
5384 /* Always increment sample row counter. */
5387 /*
5388 * Determine the slot where this sample row should be stored. Set pos to
5389 * negative value to indicate the row should be skipped.
5390 */
5392 {
5393 /* First targrows rows are always included into the sample */
5395 }
5396 else
5397 {
5398 /*
5399 * Now we start replacing tuples in the sample until we reach the end
5400 * of the relation. Same algorithm as in acquire_sample_rows in
5401 * analyze.c; see Jeff Vitter's paper.
5402 */
5407 {
5408 /* Choose a random reservoir element to replace. */
5412 }
5413 else
5414 {
5415 /* Skip this tuple. */
5417 }
5420 }
5423 {
5424 /*
5425 * Create sample tuple from current result row, and store it in the
5426 * position determined above. The tuple has to be created in anl_cxt.
5427 */
5434 NULL,
5438 }
5439 }
5441 /*
5442 * Import a foreign schema
5443 */
5446 {
5455 StringInfoData buf;
5458 i;
5461 /* Parse statement options */
5463 {
5474 else
5478 }
5480 /*
5481 * Get connection to the foreign server. Connection manager will
5482 * establish new connection if necessary.
5483 */
5488 /* Don't attempt to import collation if remote server hasn't got it */
5492 /* Create workspace for strings */
5495 /* In what follows, do not risk leaking any PGresults. */
5497 {
5498 /* Check that the schema really exists */
5516 /*
5517 * Fetch all table data from this schema, possibly restricted by
5518 * EXCEPT or LIMIT TO. (We don't actually need to pay any attention
5519 * to EXCEPT/LIMIT TO here, because the core code will filter the
5520 * statements we return according to those lists anyway. But it
5521 * should save a few cycles to not process excluded tables in the
5522 * first place.)
5523 *
5524 * Import table data for partitions only when they are explicitly
5525 * specified in LIMIT TO clause. Otherwise ignore them and only
5526 * include the definitions of the root partitioned tables to allow
5527 * access to the complete remote data set locally in the schema
5528 * imported.
5529 *
5530 * Note: because we run the connection with search_path restricted to
5531 * pg_catalog, the format_type() and pg_get_expr() outputs will always
5532 * include a schema name for types/functions in other schemas, which
5533 * is what we want.
5534 */
5536 "SELECT relname, "
5537 " attname, "
5538 " format_type(atttypid, atttypmod), "
5539 " attnotnull, "
5542 /* Generated columns are supported since Postgres 12 */
5546 else
5552 " collname, "
5554 else
5559 "FROM pg_class c "
5560 " JOIN pg_namespace n ON "
5561 " relnamespace = n.oid "
5562 " LEFT JOIN pg_attribute a ON "
5563 " attrelid = c.oid AND attnum > 0 "
5564 " AND NOT attisdropped "
5565 " LEFT JOIN pg_attrdef ad ON "
5570 " LEFT JOIN pg_collation coll ON "
5571 " coll.oid = attcollation "
5572 " LEFT JOIN pg_namespace collnsp ON "
5576 "WHERE c.relkind IN ("
5585 /* Partitions are supported since Postgres 10 */
5590 /* Apply restrictions for LIMIT TO and EXCEPT */
5593 {
5601 /* Append list of table names within IN clause */
5603 {
5608 else
5611 }
5613 }
5615 /* Append ORDER BY at the end of query to ensure output ordering */
5618 /* Fetch the data */
5623 /* Process results */
5625 /* note: incrementation of i happens in inner loop's while() test */
5627 {
5635 /* Scan all rows for this table */
5636 do
5637 {
5646 /* If table has no columns, we'll see nulls here */
5664 else
5667 /* Print column name and type */
5670 typename);
5672 /*
5673 * Add column_name option so that renaming the foreign table's
5674 * column doesn't break the association to the underlying
5675 * column.
5676 */
5681 /* Add COLLATE if needed */
5687 /* Add DEFAULT if needed */
5692 /* Add GENERATED if needed */
5695 {
5699 attdefault);
5700 }
5702 /* Add NOT NULL if needed */
5705 }
5709 /*
5710 * Add server name and table-level options. We specify remote
5711 * schema and table name as options (the latter to ensure that
5712 * renaming the foreign table doesn't break the association).
5713 */
5725 }
5726 }
5728 {
5730 }
5736 }
5738 /*
5739 * Check if reltarget is safe enough to push down semi-join. Reltarget is not
5740 * safe, if it contains references to inner rel relids, which do not belong to
5741 * outer rel.
5742 */
5743 static bool
5744 semijoin_target_ok(PlannerInfo *root, RelOptInfo *joinrel, RelOptInfo *outerrel, RelOptInfo *innerrel)
5745 {
5755 {
5763 {
5764 /*
5765 * The planner can create semi-join, which refers to inner rel
5766 * vars in its target list. However, we deparse semi-join as an
5767 * exists() subquery, so can't handle references to inner rel in
5768 * the target list.
5769 */
5772 }
5773 }
5775 }
5777 /*
5778 * Assess whether the join between inner and outer relations can be pushed down
5779 * to the foreign server. As a side effect, save information we obtain in this
5780 * function to PgFdwRelationInfo passed in.
5781 */
5782 static bool
5786 {
5793 /*
5794 * We support pushing down INNER, LEFT, RIGHT, FULL OUTER and SEMI joins.
5795 * Constructing queries representing ANTI joins is hard, hence not
5796 * considered right now.
5797 */
5803 /*
5804 * We can't push down semi-join if its reltarget is not safe
5805 */
5809 /*
5810 * If either of the joining relations is marked as unsafe to pushdown, the
5811 * join can not be pushed down.
5812 */
5820 /*
5821 * If joining relations have local conditions, those conditions are
5822 * required to be applied before joining the relations. Hence the join can
5823 * not be pushed down.
5824 */
5828 /*
5829 * Merge FDW options. We might be tempted to do this after we have deemed
5830 * the foreign join to be OK. But we must do this beforehand so that we
5831 * know which quals can be evaluated on the foreign server, which might
5832 * depend on shippable_extensions.
5833 */
5837 /*
5838 * Separate restrict list into join quals and pushed-down (other) quals.
5839 *
5840 * Join quals belonging to an outer join must all be shippable, else we
5841 * cannot execute the join remotely. Add such quals to 'joinclauses'.
5842 *
5843 * Add other quals to fpinfo->remote_conds if they are shippable, else to
5844 * fpinfo->local_conds. In an inner join it's okay to execute conditions
5845 * either locally or remotely; the same is true for pushed-down conditions
5846 * at an outer join.
5847 *
5848 * Note we might return failure after having already scribbled on
5849 * fpinfo->remote_conds and fpinfo->local_conds. That's okay because we
5850 * won't consult those lists again if we deem the join unshippable.
5851 */
5854 {
5861 {
5865 }
5866 else
5867 {
5870 else
5872 }
5873 }
5875 /*
5876 * deparseExplicitTargetList() isn't smart enough to handle anything other
5877 * than a Var. In particular, if there's some PlaceHolderVar that would
5878 * need to be evaluated within this join tree (because there's an upper
5879 * reference to a quantity that may go to NULL as a result of an outer
5880 * join), then we can't try to push the join down because we'll fail when
5881 * we get to deparseExplicitTargetList(). However, a PlaceHolderVar that
5882 * needs to be evaluated *at the top* of this join tree is OK, because we
5883 * can do that locally after fetching the results from the remote side.
5884 */
5886 {
5888 Relids relids;
5890 /* PlaceHolderInfo refers to parent relids, not child relids. */
5897 }
5899 /* Save the join clauses, for later use. */
5906 /*
5907 * By default, both the input relations are not required to be deparsed as
5908 * subqueries, but there might be some relations covered by the input
5909 * relations that are required to be deparsed as subqueries, so save the
5910 * relids of those relations for later use by the deparser.
5911 */
5921 /*
5922 * Pull the other remote conditions from the joining relations into join
5923 * clauses or other remote clauses (remote_conds) of this relation
5924 * wherever possible. This avoids building subqueries at every join step.
5925 *
5926 * For an inner join, clauses from both the relations are added to the
5927 * other remote clauses. For LEFT and RIGHT OUTER join, the clauses from
5928 * the outer side are added to remote_conds since those can be evaluated
5929 * after the join is evaluated. The clauses from inner side are added to
5930 * the joinclauses, since they need to be evaluated while constructing the
5931 * join.
5932 *
5933 * For SEMI-JOIN clauses from inner relation can not be added to
5934 * remote_conds, but should be treated as join clauses (as they are
5935 * deparsed to EXISTS subquery, where inner relation can be referred). A
5936 * list of relation ids, which can't be referred to from higher levels, is
5937 * preserved as a hidden_subquery_rels list.
5938 *
5939 * For a FULL OUTER JOIN, the other clauses from either relation can not
5940 * be added to the joinclauses or remote_conds, since each relation acts
5941 * as an outer relation for the other.
5942 *
5943 * The joining sides can not have local conditions, thus no need to test
5944 * shippability of the clauses being pulled up.
5945 */
5947 {
5981 /*
5982 * In this case, if any of the input relations has conditions, we
5983 * need to deparse that relation as a subquery so that the
5984 * conditions can be evaluated before the join. Remember it in
5985 * the fpinfo of this relation so that the deparser can take
5986 * appropriate action. Also, save the relids of base relations
5987 * covered by that relation for later use by the deparser.
5988 */
5990 {
5995 }
5997 {
6002 }
6006 /* Should not happen, we have just checked this above */
6008 }
6010 /*
6011 * For an inner join, all restrictions can be treated alike. Treating the
6012 * pushed down conditions as join conditions allows a top level full outer
6013 * join to be deparsed without requiring subqueries.
6014 */
6016 {
6020 }
6022 {
6023 /*
6024 * Conditions, generated from semi-joins, should be evaluated before
6025 * LEFT/RIGHT/FULL join.
6026 */
6028 {
6031 }
6034 {
6037 }
6038 }
6040 /* Mark that this join can be pushed down safely */
6043 /* Get user mapping */
6045 {
6048 else
6050 }
6051 else
6054 /*
6055 * Set # of retrieved rows and cached relation costs to some negative
6056 * value, so that we can detect when they are set to some sensible values,
6057 * during one (usually the first) of the calls to estimate_path_cost_size.
6058 */
6063 /*
6064 * Set the string describing this join relation to be used in EXPLAIN
6065 * output of corresponding ForeignScan. Note that the decoration we add
6066 * to the base relation names mustn't include any digits, or it'll confuse
6067 * postgresExplainForeignScan.
6068 */
6074 /*
6075 * Set the relation index. This is defined as the position of this
6076 * joinrel in the join_rel_list list plus the length of the rtable list.
6077 * Note that since this joinrel is at the end of the join_rel_list list
6078 * when we are called, we can get the position by list_length.
6079 */
6085 }
6087 static void
6090 {
6096 /*
6097 * Before creating sorted paths, arrange for the passed-in EPQ path, if
6098 * any, to return columns needed by the parent ForeignScan node so that
6099 * they will propagate up through Sort nodes injected below, if necessary.
6100 */
6102 {
6106 /* Include columns required for evaluating PHVs in the tlist. */
6109 PVC_RECURSE_PLACEHOLDERS));
6111 /* Include columns required for evaluating the local conditions. */
6113 {
6118 PVC_RECURSE_PLACEHOLDERS));
6119 }
6121 /*
6122 * If we have added any new columns, adjust the tlist of the EPQ path.
6123 *
6124 * Note: the plan created using this path will only be used to execute
6125 * EPQ checks, where accuracy of the plan cost and width estimates
6126 * would not be important, so we do not do set_pathtarget_cost_width()
6127 * for the new pathtarget here. See also postgresGetForeignPlan().
6128 */
6130 {
6131 /* The EPQ path is a join path, so it is projection-capable. */
6134 /*
6135 * Use create_projection_path() here, so as to avoid modifying it
6136 * in place.
6137 */
6139 rel,
6140 epq_path,
6141 target);
6142 }
6143 }
6145 /* Create one path for each set of pathkeys we found above. */
6147 {
6150 Cost startup_cost;
6151 Cost total_cost;
6158 /*
6159 * The EPQ path must be at least as well sorted as the path itself, in
6160 * case it gets used as input to a mergejoin.
6161 */
6168 rel,
6169 sorted_epq_path,
6170 useful_pathkeys,
6176 NULL,
6177 rows,
6178 startup_cost,
6179 total_cost,
6180 useful_pathkeys,
6182 sorted_epq_path,
6184 * list */
6185 NIL));
6186 else
6189 NULL,
6190 rows,
6191 startup_cost,
6192 total_cost,
6193 useful_pathkeys,
6195 sorted_epq_path,
6196 restrictlist,
6197 NIL));
6198 }
6199 }
6201 /*
6202 * Parse options from foreign server and apply them to fpinfo.
6203 *
6204 * New options might also require tweaking merge_fdw_options().
6205 */
6206 static void
6208 {
6212 {
6219 NULL);
6222 NULL);
6230 }
6231 }
6233 /*
6234 * Parse options from foreign table and apply them to fpinfo.
6235 *
6236 * New options might also require tweaking merge_fdw_options().
6237 */
6238 static void
6240 {
6244 {
6253 }
6254 }
6256 /*
6257 * Merge FDW options from input relations into a new set of options for a join
6258 * or an upper rel.
6259 *
6260 * For a join relation, FDW-specific information about the inner and outer
6261 * relations is provided using fpinfo_i and fpinfo_o. For an upper relation,
6262 * fpinfo_o provides the information for the input relation; fpinfo_i is
6263 * expected to NULL.
6264 */
6265 static void
6269 {
6270 /* We must always have fpinfo_o. */
6273 /* fpinfo_i may be NULL, but if present the servers must both match. */
6277 /*
6278 * Copy the server specific FDW options. (For a join, both relations come
6279 * from the same server, so the server options should have the same value
6280 * for both relations.)
6281 */
6289 /* Merge the table level options from either side of the join. */
6291 {
6292 /*
6293 * We'll prefer to use remote estimates for this join if any table
6294 * from either side of the join is using remote estimates. This is
6295 * most likely going to be preferred since they're already willing to
6296 * pay the price of a round trip to get the remote EXPLAIN. In any
6297 * case it's not entirely clear how we might otherwise handle this
6298 * best.
6299 */
6303 /*
6304 * Set fetch size to maximum of the joining sides, since we are
6305 * expecting the rows returned by the join to be proportional to the
6306 * relation sizes.
6307 */
6310 /*
6311 * We'll prefer to consider this join async-capable if any table from
6312 * either side of the join is considered async-capable. This would be
6313 * reasonable because in that case the foreign server would have its
6314 * own resources to scan that table asynchronously, and the join could
6315 * also be computed asynchronously using the resources.
6316 */
6319 }
6320 }
6322 /*
6323 * postgresGetForeignJoinPaths
6324 * Add possible ForeignPath to joinrel, if join is safe to push down.
6325 */
6326 static void
6331 JoinType jointype,
6333 {
6338 Cost startup_cost;
6339 Cost total_cost;
6341 * EvalPlanQual gets triggered. */
6343 /*
6344 * Skip if this join combination has been considered already.
6345 */
6349 /*
6350 * This code does not work for joins with lateral references, since those
6351 * must have parameterized paths, which we don't generate yet.
6352 */
6356 /*
6357 * Create unfinished PgFdwRelationInfo entry which is used to indicate
6358 * that the join relation is already considered, so that we won't waste
6359 * time in judging safety of join pushdown and adding the same paths again
6360 * if found safe. Once we know that this join can be pushed down, we fill
6361 * the entry.
6362 */
6366 /* attrs_used is only for base relations. */
6369 /*
6370 * If there is a possibility that EvalPlanQual will be executed, we need
6371 * to be able to reconstruct the row using scans of the base relations.
6372 * GetExistingLocalJoinPath will find a suitable path for this purpose in
6373 * the path list of the joinrel, if one exists. We must be careful to
6374 * call it before adding any ForeignPath, since the ForeignPath might
6375 * dominate the only suitable local path available. We also do it before
6376 * calling foreign_join_ok(), since that function updates fpinfo and marks
6377 * it as pushable if the join is found to be pushable.
6378 */
6382 {
6385 {
6386 elog(DEBUG3, "could not push down foreign join because a local path suitable for EPQ checks was not found");
6388 }
6389 }
6390 else
6394 {
6395 /* Free path required for EPQ if we copied one; we don't need it now */
6399 }
6401 /*
6402 * Compute the selectivity and cost of the local_conds, so we don't have
6403 * to do it over again for each path. The best we can do for these
6404 * conditions is to estimate selectivity on the basis of local statistics.
6405 * The local conditions are applied after the join has been computed on
6406 * the remote side like quals in WHERE clause, so pass jointype as
6407 * JOIN_INNER.
6408 */
6412 JOIN_INNER,
6413 NULL);
6416 /*
6417 * If we are going to estimate costs locally, estimate the join clause
6418 * selectivity here while we have special join info.
6419 */
6425 /* Estimate costs for bare join relation */
6428 /* Now update this information in the joinrel */
6436 /*
6437 * Create a new join path and add it to the joinrel which represents a
6438 * join between foreign tables.
6439 */
6441 joinrel,
6443 rows,
6444 startup_cost,
6445 total_cost,
6448 epq_path,
6452 /* Add generated path into joinrel by add_path(). */
6455 /* Consider pathkeys for the join relation */
6459 /* XXX Consider parameterized paths for the join relation */
6460 }
6462 /*
6463 * Assess whether the aggregation, grouping and having operations can be pushed
6464 * down to the foreign server. As a side effect, save information we obtain in
6465 * this function to PgFdwRelationInfo of the input relation.
6466 */
6467 static bool
6470 {
6479 /* We currently don't support pushing Grouping Sets. */
6483 /* Get the fpinfo of the underlying scan relation. */
6486 /*
6487 * If underlying scan relation has any local conditions, those conditions
6488 * are required to be applied before performing aggregation. Hence the
6489 * aggregate cannot be pushed down.
6490 */
6494 /*
6495 * Examine grouping expressions, as well as other expressions we'd need to
6496 * compute, and check whether they are safe to push down to the foreign
6497 * server. All GROUP BY expressions will be part of the grouping target
6498 * and thus there is no need to search for them separately. Add grouping
6499 * expressions into target list which will be passed to foreign server.
6500 *
6501 * A tricky fine point is that we must not put any expression into the
6502 * target list that is just a foreign param (that is, something that
6503 * deparse.c would conclude has to be sent to the foreign server). If we
6504 * do, the expression will also appear in the fdw_exprs list of the plan
6505 * node, and setrefs.c will get confused and decide that the fdw_exprs
6506 * entry is actually a reference to the fdw_scan_tlist entry, resulting in
6507 * a broken plan. Somewhat oddly, it's OK if the expression contains such
6508 * a node, as long as it's not at top level; then no match is possible.
6509 */
6512 {
6517 /*
6518 * Check whether this expression is part of GROUP BY clause. Note we
6519 * check the whole GROUP BY clause not just processed_groupClause,
6520 * because we will ship all of it, cf. appendGroupByClause.
6521 */
6523 {
6526 /*
6527 * If any GROUP BY expression is not shippable, then we cannot
6528 * push down aggregation to the foreign server.
6529 */
6533 /*
6534 * If it would be a foreign param, we can't put it into the tlist,
6535 * so we have to fail.
6536 */
6540 /*
6541 * Pushable, so add to tlist. We need to create a TLE for this
6542 * expression and apply the sortgroupref to it. We cannot use
6543 * add_to_flat_tlist() here because that avoids making duplicate
6544 * entries in the tlist. If there are duplicate entries with
6545 * distinct sortgrouprefs, we have to duplicate that situation in
6546 * the output tlist.
6547 */
6551 }
6552 else
6553 {
6554 /*
6555 * Non-grouping expression we need to compute. Can we ship it
6556 * as-is to the foreign server?
6557 */
6560 {
6561 /* Yes, so add to tlist as-is; OK to suppress duplicates */
6563 }
6564 else
6565 {
6566 /* Not pushable as a whole; extract its Vars and aggregates */
6570 PVC_INCLUDE_AGGREGATES);
6572 /*
6573 * If any aggregate expression is not shippable, then we
6574 * cannot push down aggregation to the foreign server. (We
6575 * don't have to check is_foreign_param, since that certainly
6576 * won't return true for any such expression.)
6577 */
6581 /*
6582 * Add aggregates, if any, into the targetlist. Plain Vars
6583 * outside an aggregate can be ignored, because they should be
6584 * either same as some GROUP BY column or part of some GROUP
6585 * BY expression. In either case, they are already part of
6586 * the targetlist and thus no need to add them again. In fact
6587 * including plain Vars in the tlist when they do not match a
6588 * GROUP BY column would cause the foreign server to complain
6589 * that the shipped query is invalid.
6590 */
6592 {
6597 }
6598 }
6599 }
6601 i++;
6602 }
6604 /*
6605 * Classify the pushable and non-pushable HAVING clauses and save them in
6606 * remote_conds and local_conds of the grouped rel's fpinfo.
6607 */
6609 {
6611 {
6615 /*
6616 * Currently, the core code doesn't wrap havingQuals in
6617 * RestrictInfos, so we must make our own.
6618 */
6621 expr,
6628 NULL,
6629 NULL);
6632 else
6634 }
6635 }
6637 /*
6638 * If there are any local conditions, pull Vars and aggregates from it and
6639 * check whether they are safe to pushdown or not.
6640 */
6642 {
6646 {
6651 PVC_INCLUDE_AGGREGATES));
6652 }
6655 {
6658 /*
6659 * If aggregates within local conditions are not safe to push
6660 * down, then we cannot push down the query. Vars are already
6661 * part of GROUP BY clause which are checked above, so no need to
6662 * access them again here. Again, we need not check
6663 * is_foreign_param for a foreign aggregate.
6664 */
6666 {
6671 }
6672 }
6673 }
6675 /* Store generated targetlist */
6678 /* Safe to pushdown */
6681 /*
6682 * Set # of retrieved rows and cached relation costs to some negative
6683 * value, so that we can detect when they are set to some sensible values,
6684 * during one (usually the first) of the calls to estimate_path_cost_size.
6685 */
6690 /*
6691 * Set the string describing this grouped relation to be used in EXPLAIN
6692 * output of corresponding ForeignScan. Note that the decoration we add
6693 * to the base relation name mustn't include any digits, or it'll confuse
6694 * postgresExplainForeignScan.
6695 */
6700 }
6702 /*
6703 * postgresGetForeignUpperPaths
6704 * Add paths for post-join operations like aggregation, grouping etc. if
6705 * corresponding operations are safe to push down.
6706 */
6707 static void
6711 {
6714 /*
6715 * If input rel is not safe to pushdown, then simply return as we cannot
6716 * perform any post-join operations on the foreign server.
6717 */
6722 /* Ignore stages we don't support; and skip any duplicate calls. */
6735 {
6750 }
6751 }
6753 /*
6754 * add_foreign_grouping_paths
6755 * Add foreign path for grouping and/or aggregation.
6756 *
6757 * Given input_rel represents the underlying scan. The paths are added to the
6758 * given grouped_rel.
6759 */
6760 static void
6764 {
6771 Cost startup_cost;
6772 Cost total_cost;
6774 /* Nothing to be done, if there is no grouping or aggregation required. */
6782 /* save the input_rel as outerrel in fpinfo */
6785 /*
6786 * Copy foreign table, foreign server, user mapping, FDW options etc.
6787 * details from the input relation's fpinfo.
6788 */
6794 /*
6795 * Assess if it is safe to push down aggregation and grouping.
6796 *
6797 * Use HAVING qual from extra. In case of child partition, it will have
6798 * translated Vars.
6799 */
6803 /*
6804 * Compute the selectivity and cost of the local_conds, so we don't have
6805 * to do it over again for each path. (Currently we create just a single
6806 * path here, but in future it would be possible that we build more paths
6807 * such as pre-sorted paths as in postgresGetForeignPaths and
6808 * postgresGetForeignJoinPaths.) The best we can do for these conditions
6809 * is to estimate selectivity on the basis of local statistics.
6810 */
6814 JOIN_INNER,
6815 NULL);
6819 /* Estimate the cost of push down */
6823 /* Now update this information in the fpinfo */
6829 /* Create and add foreign path to the grouping relation. */
6831 grouped_rel,
6833 rows,
6834 startup_cost,
6835 total_cost,
6837 NULL,
6841 /* Add generated path into grouped_rel by add_path(). */
6843 }
6845 /*
6846 * add_foreign_ordered_paths
6847 * Add foreign paths for performing the final sort remotely.
6848 *
6849 * Given input_rel contains the source-data Paths. The paths are added to the
6850 * given ordered_rel.
6851 */
6852 static void
6855 {
6862 Cost startup_cost;
6863 Cost total_cost;
6868 /* Shouldn't get here unless the query has ORDER BY */
6871 /* We don't support cases where there are any SRFs in the targetlist */
6875 /* Save the input_rel as outerrel in fpinfo */
6878 /*
6879 * Copy foreign table, foreign server, user mapping, FDW options etc.
6880 * details from the input relation's fpinfo.
6881 */
6887 /*
6888 * If the input_rel is a base or join relation, we would already have
6889 * considered pushing down the final sort to the remote server when
6890 * creating pre-sorted foreign paths for that relation, because the
6891 * query_pathkeys is set to the root->sort_pathkeys in that case (see
6892 * standard_qp_callback()).
6893 */
6896 {
6899 /* Safe to push down if the query_pathkeys is safe to push down */
6903 }
6905 /* The input_rel should be a grouping relation */
6909 /*
6910 * We try to create a path below by extending a simple foreign path for
6911 * the underlying grouping relation to perform the final sort remotely,
6912 * which is stored into the fdw_private list of the resulting path.
6913 */
6915 /* Assess if it is safe to push down the final sort */
6917 {
6921 /*
6922 * is_foreign_expr would detect volatile expressions as well, but
6923 * checking ec_has_volatile here saves some cycles.
6924 */
6928 /*
6929 * Can't push down the sort if pathkey's opfamily is not shippable.
6930 */
6932 fpinfo))
6935 /*
6936 * The EC must contain a shippable EM that is computed in input_rel's
6937 * reltarget, else we can't push down the sort.
6938 */
6940 pathkey_ec,
6943 }
6945 /* Safe to push down */
6948 /* Construct PgFdwPathExtraData */
6953 /* Estimate the costs of performing the final sort remotely */
6957 /*
6958 * Build the fdw_private list that will be used by postgresGetForeignPlan.
6959 * Items in the list must match order in enum FdwPathPrivateIndex.
6960 */
6963 /* Create foreign ordering path */
6965 input_rel,
6967 rows,
6968 startup_cost,
6969 total_cost,
6973 * list */
6974 fdw_private);
6976 /* and add it to the ordered_rel */
6978 }
6980 /*
6981 * add_foreign_final_paths
6982 * Add foreign paths for performing the final processing remotely.
6983 *
6984 * Given input_rel contains the source-data Paths. The paths are added to the
6985 * given final_rel.
6986 */
6987 static void
6991 {
7001 Cost startup_cost;
7002 Cost total_cost;
7006 /*
7007 * Currently, we only support this for SELECT commands
7008 */
7012 /*
7013 * No work if there is no FOR UPDATE/SHARE clause and if there is no need
7014 * to add a LIMIT node
7015 */
7019 /* We don't support cases where there are any SRFs in the targetlist */
7023 /* Save the input_rel as outerrel in fpinfo */
7026 /*
7027 * Copy foreign table, foreign server, user mapping, FDW options etc.
7028 * details from the input relation's fpinfo.
7029 */
7035 /*
7036 * If there is no need to add a LIMIT node, there might be a ForeignPath
7037 * in the input_rel's pathlist that implements all behavior of the query.
7038 * Note: we would already have accounted for the query's FOR UPDATE/SHARE
7039 * (if any) before we get here.
7040 */
7042 {
7047 /*
7048 * Grouping and aggregation are not supported with FOR UPDATE/SHARE,
7049 * so the input_rel should be a base, join, or ordered relation; and
7050 * if it's an ordered relation, its input relation should be a base or
7051 * join relation.
7052 */
7061 {
7064 /*
7065 * apply_scanjoin_target_to_paths() uses create_projection_path()
7066 * to adjust each of its input paths if needed, whereas
7067 * create_ordered_paths() uses apply_projection_to_path() to do
7068 * that. So the former might have put a ProjectionPath on top of
7069 * the ForeignPath; look through ProjectionPath and see if the
7070 * path underneath it is ForeignPath.
7071 */
7075 {
7076 /*
7077 * Create foreign final path; this gets rid of a
7078 * no-longer-needed outer plan (if any), which makes the
7079 * EXPLAIN output look cleaner
7080 */
7090 * list */
7093 /* and add it to the final_rel */
7096 /* Safe to push down */
7100 }
7101 }
7103 /*
7104 * If we get here it means no ForeignPaths; since we would already
7105 * have considered pushing down all operations for the query to the
7106 * remote server, give up on it.
7107 */
7109 }
7113 /*
7114 * If the input_rel is an ordered relation, replace the input_rel with its
7115 * input relation
7116 */
7119 {
7124 }
7126 /* The input_rel should be a base, join, or grouping relation */
7132 /*
7133 * We try to create a path below by extending a simple foreign path for
7134 * the underlying base, join, or grouping relation to perform the final
7135 * sort (if has_final_sort) and the LIMIT restriction remotely, which is
7136 * stored into the fdw_private list of the resulting path. (We
7137 * re-estimate the costs of sorting the underlying relation, if
7138 * has_final_sort.)
7139 */
7141 /*
7142 * Assess if it is safe to push down the LIMIT and OFFSET to the remote
7143 * server
7144 */
7146 /*
7147 * If the underlying relation has any local conditions, the LIMIT/OFFSET
7148 * cannot be pushed down.
7149 */
7153 /*
7154 * If the query has FETCH FIRST .. WITH TIES, 1) it must have ORDER BY as
7155 * well, which is used to determine which additional rows tie for the last
7156 * place in the result set, and 2) ORDER BY must already have been
7157 * determined to be safe to push down before we get here. So in that case
7158 * the FETCH clause is safe to push down with ORDER BY if the remote
7159 * server is v13 or later, but if not, the remote query will fail entirely
7160 * for lack of support for it. Since we do not currently have a way to do
7161 * a remote-version check (without accessing the remote server), disable
7162 * pushing the FETCH clause for now.
7163 */
7167 /*
7168 * Also, the LIMIT/OFFSET cannot be pushed down, if their expressions are
7169 * not safe to remote.
7170 */
7175 /* Safe to push down */
7178 /* Construct PgFdwPathExtraData */
7187 /*
7188 * Estimate the costs of performing the final sort and the LIMIT
7189 * restriction remotely. If has_final_sort is false, we wouldn't need to
7190 * execute EXPLAIN anymore if use_remote_estimate, since the costs can be
7191 * roughly estimated using the costs we already have for the underlying
7192 * relation, in the same way as when use_remote_estimate is false. Since
7193 * it's pretty expensive to execute EXPLAIN, force use_remote_estimate to
7194 * false in that case.
7195 */
7197 {
7200 }
7206 /*
7207 * Build the fdw_private list that will be used by postgresGetForeignPlan.
7208 * Items in the list must match order in enum FdwPathPrivateIndex.
7209 */
7213 /*
7214 * Create foreign final path; this gets rid of a no-longer-needed outer
7215 * plan (if any), which makes the EXPLAIN output look cleaner
7216 */
7218 input_rel,
7220 rows,
7221 startup_cost,
7222 total_cost,
7223 pathkeys,
7226 fdw_private);
7228 /* and add it to the final_rel */
7230 }
7232 /*
7233 * postgresIsForeignPathAsyncCapable
7234 * Check whether a given ForeignPath node is async-capable.
7235 */
7236 static bool
7238 {
7243 }
7245 /*
7246 * postgresForeignAsyncRequest
7247 * Asynchronously request next tuple from a foreign PostgreSQL table.
7248 */
7249 static void
7251 {
7253 }
7255 /*
7256 * postgresForeignAsyncConfigureWait
7257 * Configure a file descriptor event for which we wish to wait.
7258 */
7259 static void
7261 {
7268 /* This should not be called unless callback_pending */
7271 /*
7272 * If process_pending_request() has been invoked on the given request
7273 * before we get here, we might have some tuples already; in which case
7274 * complete the request
7275 */
7277 {
7282 }
7284 /* We must have run out of tuples */
7287 /* The core code would have registered postmaster death event */
7290 /* Begin an asynchronous data fetch if not already done */
7294 {
7295 /*
7296 * This is the case when the in-process request was made by another
7297 * Append. Note that it might be useless to process the request made
7298 * by that Append, because the query might not need tuples from that
7299 * Append anymore; so we avoid processing it to begin a fetch for the
7300 * given request if possible. If there are any child subplans of the
7301 * same parent that are ready for new requests, skip the given
7302 * request. Likewise, if there are any configured events other than
7303 * the postmaster death event, skip it. Otherwise, process the
7304 * in-process request, then begin a fetch to configure the event
7305 * below, because we might otherwise end up with no configured events
7306 * other than the postmaster death event.
7307 */
7314 }
7316 {
7317 /*
7318 * This is the case when the in-process request was made by the same
7319 * parent but for a different child. Since we configure only the
7320 * event for the request made for that child, skip the given request.
7321 */
7323 }
7324 else
7329 }
7331 /*
7332 * postgresForeignAsyncNotify
7333 * Fetch some more tuples from a file descriptor that becomes ready,
7334 * requesting next tuple.
7335 */
7336 static void
7338 {
7342 /* The core code would have initialized the callback_pending flag */
7345 /*
7346 * If process_pending_request() has been invoked on the given request
7347 * before we get here, we might have some tuples already; in which case
7348 * produce the next tuple
7349 */
7351 {
7354 }
7356 /* We must have run out of tuples */
7359 /* The request should be currently in-process */
7362 /* On error, report the original query, not the FETCH. */
7369 }
7371 /*
7372 * Asynchronously produce next tuple from a foreign PostgreSQL table.
7373 */
7374 static void
7376 {
7382 /* This should not be called if the request is currently in-process */
7385 /* Fetch some more tuples, if we've run out */
7387 {
7388 /* No point in another fetch if we already detected EOF, though */
7390 {
7391 /* Mark the request as pending for a callback */
7393 /* Begin another fetch if requested and if no pending request */
7396 }
7397 else
7398 {
7399 /* There's nothing more to do; just return a NULL pointer */
7401 /* Mark the request as complete */
7403 }
7405 }
7407 /* Get a tuple from the ForeignScan node */
7410 {
7411 /* Mark the request as complete */
7414 }
7416 /* We must have run out of tuples */
7419 /* Fetch some more tuples, if we've not detected EOF yet */
7421 {
7422 /* Mark the request as pending for a callback */
7424 /* Begin another fetch if requested and if no pending request */
7427 }
7428 else
7429 {
7430 /* There's nothing more to do; just return a NULL pointer */
7432 /* Mark the request as complete */
7434 }
7435 }
7437 /*
7438 * Begin an asynchronous data fetch.
7439 *
7440 * Note: this function assumes there is no currently-in-progress asynchronous
7441 * data fetch.
7442 *
7443 * Note: fetch_more_data must be called to fetch the result.
7444 */
7445 static void
7447 {
7454 /* Create the cursor synchronously. */
7458 /* We will send this query, but not wait for the response. */
7465 /* Remember that the request is in process */
7467 }
7469 /*
7470 * Process a pending asynchronous request.
7471 */
7472 void
7474 {
7478 /* The request would have been pending for a callback */
7481 /* The request should be currently in-process */
7486 /*
7487 * If we didn't get any tuples, must be end of data; complete the request
7488 * now. Otherwise, we postpone completing the request until we are called
7489 * from postgresForeignAsyncConfigureWait()/postgresForeignAsyncNotify().
7490 */
7492 {
7493 /* Unlike AsyncNotify, we unset callback_pending ourselves */
7495 /* Mark the request as complete */
7497 /* Unlike AsyncNotify, we call ExecAsyncResponse ourselves */
7499 }
7500 }
7502 /*
7503 * Complete a pending asynchronous request.
7504 */
7505 static void
7507 {
7508 /* The request would have been pending for a callback */
7511 /* Unlike AsyncNotify, we unset callback_pending ourselves */
7514 /* We begin a fetch afterwards if necessary; don't fetch */
7517 /* Unlike AsyncNotify, we call ExecAsyncResponse ourselves */
7520 /* Also, we do instrumentation ourselves, if required */
7524 }
7526 /*
7527 * Create a tuple from the specified row of the PGresult.
7528 *
7529 * rel is the local representation of the foreign table, attinmeta is
7530 * conversion data for the rel's tupdesc, and retrieved_attrs is an
7531 * integer list of the table column numbers present in the PGresult.
7532 * fsstate is the ForeignScan plan node's execution state.
7533 * temp_context is a working context that can be reset after each tuple.
7534 *
7535 * Note: either rel or fsstate, but not both, can be NULL. rel is NULL
7536 * if we're processing a remote join, while fsstate is NULL in a non-query
7537 * context such as ANALYZE, or if we're processing a non-scan query node.
7538 */
7539 static HeapTuple
7542 Relation rel,
7546 MemoryContext temp_context)
7547 {
7548 HeapTuple tuple;
7549 TupleDesc tupdesc;
7553 ConversionLocation errpos;
7554 ErrorContextCallback errcallback;
7555 MemoryContext oldcontext;
7561 /*
7562 * Do the following work in a temp context that we reset after each tuple.
7563 * This cleans up not only the data we have direct access to, but any
7564 * cruft the I/O functions might leak.
7565 */
7568 /*
7569 * Get the tuple descriptor for the row. Use the rel's tupdesc if rel is
7570 * provided, otherwise look to the scan node's ScanTupleSlot.
7571 */
7574 else
7575 {
7578 }
7582 /* Initialize to nulls for any columns not present in result */
7585 /*
7586 * Set up and install callback to report where conversion error occurs.
7587 */
7596 /*
7597 * i indexes columns in the relation, j indexes columns in the PGresult.
7598 */
7601 {
7605 /* fetch next column's textual value */
7608 else
7611 /*
7612 * convert value to internal representation
7613 *
7614 * Note: we ignore system columns other than ctid and oid in result
7615 */
7618 {
7619 /* ordinary column */
7622 /* Apply the input function even to nulls, to support domains */
7624 valstr,
7627 }
7629 {
7630 /* ctid */
7632 {
7633 Datum datum;
7637 }
7638 }
7641 j++;
7642 }
7644 /* Uninstall error context callback. */
7647 /*
7648 * Check we got the expected number of columns. Note: j == 0 and
7649 * PQnfields == 1 is expected, since deparse emits a NULL if no columns.
7650 */
7654 /*
7655 * Build the result tuple in caller's memory context.
7656 */
7661 /*
7662 * If we have a CTID to return, install it in both t_self and t_ctid.
7663 * t_self is the normal place, but if the tuple is converted to a
7664 * composite Datum, t_self will be lost; setting t_ctid allows CTID to be
7665 * preserved during EvalPlanQual re-evaluations (see ROW_MARK_COPY code).
7666 */
7670 /*
7671 * Stomp on the xmin, xmax, and cmin fields from the tuple created by
7672 * heap_form_tuple. heap_form_tuple actually creates the tuple with
7673 * DatumTupleFields, not HeapTupleFields, but the executor expects
7674 * HeapTupleFields and will happily extract system columns on that
7675 * assumption. If we don't do this then, for example, the tuple length
7676 * ends up in the xmin field, which isn't what we want.
7677 */
7682 /* Clean up */
7686 }
7688 /*
7689 * Callback function which is called when error occurs during column value
7690 * conversion. Print names of column and relation.
7691 *
7692 * Note that this function mustn't do any catalog lookups, since we are in
7693 * an already-failed transaction. Fortunately, we can get the needed info
7694 * from the relation or the query's rangetable instead.
7695 */
7696 static void
7698 {
7706 /*
7707 * If we're in a scan node, always use aliases from the rangetable, for
7708 * consistency between the simple-relation and remote-join cases. Look at
7709 * the relation's tupdesc only if we're not in a scan node.
7710 */
7712 {
7713 /* ForeignScan case */
7719 {
7720 /* error occurred in a scan against a foreign table */
7723 }
7724 else
7725 {
7726 /* error occurred in a scan against a foreign join */
7732 /*
7733 * Target list can have Vars and expressions. For Vars, we can
7734 * get some information, however for expressions we can't. Thus
7735 * for expressions, just show generic context message.
7736 */
7738 {
7743 }
7744 }
7747 {
7759 }
7760 }
7762 {
7763 /* Non-ForeignScan case (we should always have a rel here) */
7768 {
7773 }
7776 }
7782 else
7785 }
7787 /*
7788 * Given an EquivalenceClass and a foreign relation, find an EC member
7789 * that can be used to sort the relation remotely according to a pathkey
7790 * using this EC.
7791 *
7792 * If there is more than one suitable candidate, return an arbitrary
7793 * one of them. If there is none, return NULL.
7794 *
7795 * This checks that the EC member expression uses only Vars from the given
7796 * rel and is shippable. Caller must separately verify that the pathkey's
7797 * ordering operator is shippable.
7798 */
7799 EquivalenceMember *
7801 {
7807 {
7810 /*
7811 * Note we require !bms_is_empty, else we'd accept constant
7812 * expressions which are not suitable for the purpose.
7813 */
7819 }
7822 }
7824 /*
7825 * Find an EquivalenceClass member that is to be computed as a sort column
7826 * in the given rel's reltarget, and is shippable.
7827 *
7828 * If there is more than one suitable candidate, return an arbitrary
7829 * one of them. If there is none, return NULL.
7830 *
7831 * This checks that the EC member expression uses only Vars from the given
7832 * rel and is shippable. Caller must separately verify that the pathkey's
7833 * ordering operator is shippable.
7834 */
7835 EquivalenceMember *
7838 {
7845 {
7850 /* Ignore non-sort expressions */
7854 {
7855 i++;
7857 }
7859 /* We ignore binary-compatible relabeling on both ends */
7863 /* Locate an EquivalenceClass member matching this expr, if any */
7865 {
7869 /* Don't match constants */
7873 /* Ignore child members */
7877 /* Match if same expression (after stripping relabel) */
7885 /* Check that expression (including relabels!) is shippable */
7888 }
7890 i++;
7891 }
7894 }
7896 /*
7897 * Determine batch size for a given foreign table. The option specified for
7898 * a table has precedence.
7899 */
7900 static int
7902 {
7909 /* we use 1 by default, which means "no batching" */
7912 /*
7913 * Load options for table and server. We append server options after table
7914 * options, because table options take precedence.
7915 */
7923 /* See if either table or server specifies batch_size. */
7925 {
7929 {
7932 }
7933 }
7936 }