Re: make add_paths_to_append_rel aware of startup cost - Mailing list pgsql-hackers

From Andy Fan
Subject Re: make add_paths_to_append_rel aware of startup cost
Date
Msg-id CAKU4AWpKXqK5fJ1RdDRY8E17jNbKHxseHwaTgDcK6RXSDD5Fbg@mail.gmail.com
Whole thread Raw
In response to make add_paths_to_append_rel aware of startup cost  (Andy Fan <zhihui.fan1213@gmail.com>)
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Quoting filename in using facing log messages
Next
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition