Re: add_path optimization - Mailing list pgsql-hackers

From Tom Lane
Subject Re: add_path optimization
Date
Msg-id 3740.1233767498@sss.pgh.pa.us
Whole thread Raw
In response to Re: add_path optimization  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: add_path optimization  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Hot standby, recovery infra
Next
From: "Kevin Grittner"
Date:
Subject: Re: add_path optimization