Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Mar 5, 2013 at 3:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If "foo OR bar" is useful as an indexqual condition in the inner scan,
>> that's one thing. But if it isn't, the cycles expended to check it in
>> the inner scan are possibly wasted, because we'll still have to check
>> the full original OR clause later. It's possible that the filter
>> condition removes enough rows from the inner scan's result to justify
>> the redundant checks, but it's at least as possible that it doesn't.
> Yeah, that's pretty unappealing. It probably doesn't matter much if
> foo is just a column reference, but what if it's an expensive
> function? For that matter, what if it's a volatile function that we
> can't execute twice without changing the results?
Well, *that* worry at least is a nonissue: if the clause contains
volatile functions then it's not a candidate to be an indexqual anyway.
The code that pulls out these simplified OR clauses is only looking for
clauses that can be shown to match existing indexes, so it won't pick
anything like that. But expensive functions could be a hazard.
>> (Hm, maybe what we need is a marker for "enforce this clause
>> only if you feel like it"?)
> Not sure I get the parenthesized bit.
I was thinking that we'd extract the simplified clause and then mark it
as something to be used only if it can be used as an indexqual.
However, on second thought that still leaves us with the problem that
some parameterized paths yield more rows than others. Maybe that
assumption simply has to go ...
regards, tom lane