From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rowcounts marked by create_foreignscan_path() |
Date: | 2014-02-18 03:37:48 |
Message-ID: | 13530.1392694668@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2014-02-18 03:43:53 | Description for pg_replslot in docs |
Previous Message | Etsuro Fujita | 2014-02-18 03:25:01 | Re: Rowcounts marked by create_foreignscan_path() |