Re: Rowcounts marked by create_foreignscan_path()

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

In response to

Responses

Browse pgsql-hackers by date

  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()