> On Feb 26, 2019, at 2:19 PM, Tom Lane <tgl@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
tohave 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’tbe a constant on either side of the operator. Am I mis-understanding the term, or are there issues with using this
APIin 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
