Re: inconsistent results querying table partitioned by date

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> Thanks for working on this. I did have a look and was a bit
> disappointed to see the code will end up calling pull_exec_paramids()
> 3 times for any expression with exec param IDs. I can knock that down
> to just 2 by caching the exec Param IDs of the used quals in
> GeneratePruningStepsContext. I imagine you didn't do this since its
> possible we reject the qual even after has_exec_param is set,

Exactly.

> but if
> we just delay recording the param IDs until after we're certain we're
> using the qual then it should be safe to do this.

I thought about that too, but it seems awfully messy/fragile; it's not
clear to me at what point this code is really guaranteed to have accepted
a clause. The recursion for AND/OR, in particular, seems to make that
kind of questionable.

If we could be sure about that I'd be inclined to apply the principle
to the has_mutable_arg and has_exec_param flags as well as exec_paramids,
and change the order of tests in match_clause_to_partition_key back to
what it was, relying on the outer control layer to not propagate that
data into the overall state until we knew whether the clause was really
going to contribute to the steps.

regards, tom lane