> On Feb 26, 2019, at 2:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > In most cases, multiple matching arguments are going to lead to > failure to construct any useful index condition, because your > comparison value has to be a pseudoconstant (ie, not a variable > from the same table, so in both of the above examples there's > no function argument you could compare to).
This term “pseudoconstant” has been causing me some worry as it crops up in your explanations a fair amount. I expect to have queries of the form SELECT a.*, b.* FROM a JOIN b ON ST_Intersects(a.geom, b.geom) And I expect to be able to rewrite that in terms of having an additional call to the index operator (&&) and there won’t be a constant on either side of the operator. Am I mis-understanding the term, or are there issues with using this API in a join context? P. > But we don't prejudge > that, because it's possible that a function with 3 or more arguments > could produce something useful anyway. For instance, if what we've > got is "f(x, y, constant)" then it's possible that the semantics of > the function are such that y can be ignored and we can make something > indexable like "x && constant". All this is the support function's > job to know. > regards, tom lane
