From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rowcounts marked by create_foreignscan_path() |
Date: | 2014-03-03 08:45:47 |
Message-ID: | 5314413B.7000204@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(2014/02/18 12:37), Tom Lane wrote:
> 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.
>
>> 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?
Maybe I'm missing something. But I don't think
postgresGetForeignPaths() marks the parameterized path with the correct
row estimate. Also, that function doesn't seem to estimate the cost of
the parameterized path correctly. Please find attached a patch.
> 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.
Understood. Thank you for the analysis.
Sorry for the delay.
Best regards,
Etsuro Fujita
Attachment | Content-Type | Size |
---|---|---|
postgres_fdw_path_cost_size.patch | text/plain | 7.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Kruse | 2014-03-03 09:34:23 | Re: [PATCH] Use MAP_HUGETLB where supported (v3) |
Previous Message | Pavel Stehule | 2014-03-03 07:55:21 | Re: proposal, patch: allow multiple plpgsql plugins |