From: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Allowing extensions to supply operator-/function-specific info |
Date: | 2019-02-26 23:59:35 |
Message-ID: | 91BAE1F4-7C16-4F87-849F-B01175A8D7D8@cleverelephant.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Feb 26, 2019, at 2:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Li, Zheng | 2019-02-27 00:05:41 | Re: NOT IN subquery optimization |
Previous Message | Tom Lane | 2019-02-26 23:55:29 | Re: Segfault when restoring -Fd dump on current HEAD |