Re: add_path optimization

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Well, of the cases which are selected based on the other criteria,
> there would be about one CaseDispo row each. The main selection
> criterion is the Party.searchName, with various security limitations
> added. Where one or more CaseDispo rows exist (it's only included
> through a LEFT JOIN), we want only the one with the latest dispoDate.
> Based on the queries which ran under 8.3.5, it's pretty safe to assume
> that the number of CaseDispo rows matching the join criteria to Case
> would be between 2,300 and 2,400, with only a handful having multiple
> matches to the same Case.

Hmm ... but that's all irrelevant because this is being done as the
innermost join, ie, it's running the EXISTS test for every row of
CaseDispo regardless of whether that row will be joined to later.
Based on your comments that seems like a really stupid plan choice, so
I guess Robert is right: there's some sort of logic bug here someplace.
Will look.

regards, tom lane