Message-ID: <50115756.6000109@engene.se>
Date: Thu, 26 Jul 2012 16:42:30 +0200
From: Marcus Engene <mengpg2@engene.se>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
	rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: planner, *_collapse_limit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I've read a little bit about join_collapse_limit and from_collapse_limit 
and I see their reason to exist.

A stupid question: in algorithms 101 you're usually told to make a chess 
program and then you usually do a width first min max tree. A low level 
opponent would interrupt this possibly infinite traversal early, thus 
returning a possibly bad move, and if it's on a higher level it's 
allowed to work longer and it will likely present a better path in the tree.

I understood it as that the *_collapse_limits are to stop a worst case 
join making the optimizer going haywire, but it feels sad that trivial 
big joins are cut off even if they're not too nasty.

Why would it not make some sense to have some time/space constraint on 
the join heuristics instead of/in combination to how the limit presently 
work? If we hit the ceiling, the best produced plan so far is used. The 
chess analogy would obviously be a handful chess pieces left but the 
min-max-tree traversal constraint is on a low depth (rather than 
time/memory) so it would quickly traverse the few options and then be 
constrained.

Best regards,
Marcus