Re: pgsql_fdw, FDW for PostgreSQL server

Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)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