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()
|
Список | 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 по дате отправления: