postgres_fdw: estimate_path_cost_size fails to re-use cached costs

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема postgres_fdw: estimate_path_cost_size fails to re-use cached costs
Дата
Msg-id 5C4AF3F3.4060409@lab.ntt.co.jp
обсуждение исходный текст
Ответы Re: postgres_fdw: estimate_path_cost_size fails to re-use cachedcosts  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список pgsql-hackers
Hi,

I noticed yet another thing while updating the patch for pushing down
ORDER BY LIMIT.  Let me explain.  When costing foreign paths on the
basis of local statistics, we calculate/cache the costs of an unsorted
foreign path, and re-use them to estimate the costs of presorted foreign
paths, as shown below.  BUT: we fail to re-use them for some typical
queries, such as "select * from ft1 order by a", due to
fpinfo->rel_startup_cost=0, leading to doing the same cost calculation
repeatedly.

        /*
         * We will come here again and again with different set of pathkeys
         * that caller wants to cost. We don't need to calculate the cost of
         * bare scan each time. Instead, use the costs if we have cached
them
         * already.
         */
        if (fpinfo->rel_startup_cost > 0 && fpinfo->rel_total_cost > 0)
        {
            startup_cost = fpinfo->rel_startup_cost;
            run_cost = fpinfo->rel_total_cost - fpinfo->rel_startup_cost;
        }

I think we should use "fpinfo->rel_startup_cost >= 0" here, not
"fpinfo->rel_startup_cost > 0".  Also, it would be possible that the
total cost calculated is zero in corner cases (eg, seq_page_cost=0 and
cpu_tuple_cost=0 for the example), so I think we should change the total
cost part as well.  Attached is a patch for that.

Best regards,
Etsuro Fujita

Вложения

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistentmemory