Shigeru Hanada <shigeru.han...@gmail.com> writes: > I've not read whole of the patch yet, but I have basic questions.
> 1) IIUC, GetForeignRelSize should set baserel->rows to the number of > rows the ForeignScan node returns to upper node, but not the number > of rows FDW returns to core executor, right? It should be the number of rows estimated to pass the baserestrictinfo restriction clauses, so yeah, not the same as what the FDW would return, except in cases where all the restriction clauses are handled internally by the FDW. > BTW, once Fujita-san's ANALYZE support patch is merged, we will be > able to get rows estimatation easily by calling clauselist_selectivity > with baserel->tuples and baserestrictinfo. Otherwise, pgsql_fdw > would still need to execute EXPLAIN on remote side to get meaningful > rows estimation. Yeah, one of the issues for that patch is how we see it coexisting with the option of doing a remote-side EXPLAIN. > 2) ISTM that pgsql_fdw needs to execute EXPLAIN on remote side for each > possible remote query to get meaningful costs estimation, and it > requires pgsql_fdw to generate SQL statements in GetForeignPaths. > I worry that I've misunderstood intention of your design because > you've mentioned postponing SQL deparsing to createplan time. If you want to get the cost estimates that way, then yes, you'd be needing to do some SQL-statement-construction earlier than final plan generation. But it's not apparent to me that those statements would necessarily be the same as, or even very similar to, what the final queries would be. For instance, you'd probably try to reduce parameters to constants for estimation purposes. > GetForeignPaths > 1) Repeat for each possible remote query: > 1-1) Generate remote query, such as with-WHERE and with-ORDER BY. > 1-2) Execute EXPLAIN of generated query, and get costs estimation > (rows estimation is ignored because it's useless in planning). Why do you say that? regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers