"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Introduce JOIN_SEMI and JOIN_ANTI join types, the former replacing
>> JOIN_IN.
> It just struck me that this may cause additional joins to count
> against the join_collapse_limit. If so, that could cause some
> borderline queries to optimize poorly if the limit isn't raised. Is
> that a reasonable concern? Possibly something to document in the
> release notes?
I don't think we should change anything there. The collapse limit
settings are mainly driven by not wanting to get into an exponential
growth of planning time, and the way in which join situations are
created doesn't really affect the appropriate value one way or the
other.
In a case where this did happen, you'd just have exchanged one
suboptimal planning situation for another, so I'm unconvinced that it'd
make matters any worse compared to prior releases. (That does seem like
a point worth testing, though, if you want to.)
regards, tom lane
