Re: Rowcounts marked by create_foreignscan_path() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rowcounts marked by create_foreignscan_path()
Date
Msg-id 13530.1392694668@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rowcounts marked by create_foreignscan_path()  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Rowcounts marked by create_foreignscan_path()  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> (2014/02/18 12:03), Tom Lane wrote:
>> The calling FDW is supposed to do that; note the header comment.

> Understood.  However, ISTM postgresGetForeignPaths() doesn't work like
> that.  It uses the same rowcount for all paths of a same parameterization?

That's what we want no?

Anyway, the point of using ppi_rows would be to enforce that all the
rowcount estimates for a given parameterized relation are the same.
In the FDW case, all those estimates are the FDW's responsibility,
and so making them consistent is also its responsibility IMO.

Another way of looking at this is that none of the pathnode creation
routines in pathnode.c are responsible for setting rowcount estimates.
That's done by whatever is setting the cost estimate; this must be so,
else the cost estimate is surely bogus.  So any way you slice it, the
FDW has to get it right.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Rowcounts marked by create_foreignscan_path()
Next
From: Amit Kapila
Date:
Subject: Description for pg_replslot in docs