Re: make add_paths_to_append_rel aware of startup cost

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: make add_paths_to_append_rel aware of startup cost
Дата
Msg-id CAKU4AWpKXqK5fJ1RdDRY8E17jNbKHxseHwaTgDcK6RXSDD5Fbg@mail.gmail.com
обсуждение исходный текст
Ответ на make add_paths_to_append_rel aware of startup cost  (Andy Fan <zhihui.fan1213@gmail.com>)
Список pgsql-hackers
 
- We shouldn't do the optimization if there are still more tables to join,
  the reason is similar to has_multiple_baserels(root) in
  set_subquery_pathlist. 

After some internal discussion, we have 2 different choices here. Let's
call the current choice as method-a, and the new choice as method-b.
Method-b will just ignore the "no more tables to join "limitation
and build the append path with both cheapest startup cost and cheapest
total cost, this is pretty like the method we joins a plain relation with
another relation. The uneasy part is it is the cheapest start up cost
rather than the cheapest fractional cost.

method-a is pretty same as what set_subquery_pathlist is doing, which has
a limitation on "no more tables to join" and has no the "cheapest startup
cost" part.

Ideally we can apply both strategies if we don't consider the effort. If
there are no more tables to join, we use method-a. otherwise use 
method-b. With this thinking, we can even apply the same strategy to plain
relations as well.

However, I am not sure if the "cheapest startup cost" is a real problem. 
If it is not, we can apply method-b directly and modify 
set_subquery_pathlist to do the same for consistency.  


--
Best Regards
Andy Fan

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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Quoting filename in using facing log messages
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Row pattern recognition