Re: Rowcounts marked by create_foreignscan_path()

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Rowcounts marked by create_foreignscan_path()
Дата
Msg-id 5314413B.7000204@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Rowcounts marked by create_foreignscan_path()  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Rowcounts marked by create_foreignscan_path()  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
(2014/02/18 12:37), Tom Lane wrote:
> 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.
>
>> 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal, patch: allow multiple plpgsql plugins
Следующее
От: Christian Kruse
Дата:
Сообщение: Re: [PATCH] Use MAP_HUGETLB where supported (v3)