Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gyl4B-0007c3-2t for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Feb 2019 22:19:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gyl49-0003no-7g for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Feb 2019 22:19:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gyl49-0003nR-0Y for pgsql-hackers@lists.postgresql.org; Tue, 26 Feb 2019 22:19:09 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gyl46-0005KW-1M for pgsql-hackers@lists.postgresql.org; Tue, 26 Feb 2019 22:19:08 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x1QMJ1sr014748; Tue, 26 Feb 2019 17:19:01 -0500 From: Tom Lane To: Paul Ramsey cc: PostgreSQL Hackers Subject: Re: Allowing extensions to supply operator-/function-specific info In-reply-to: References: <15193.1548028093@sss.pgh.pa.us> <6953.1548297558@sss.pgh.pa.us> <6044.1548524131@sss.pgh.pa.us> <19993.1548697885@sss.pgh.pa.us> <7671.1551135674@sss.pgh.pa.us> <11051.1551139751@sss.pgh.pa.us> Comments: In-reply-to Paul Ramsey message dated "Tue, 26 Feb 2019 13:23:36 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14746.1551219541.1@sss.pgh.pa.us> Date: Tue, 26 Feb 2019 17:19:01 -0500 Message-ID: <14747.1551219541@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Paul Ramsey writes: > New line of questioning: under what conditions will the support > function be called in a T_SupportRequestIndexCondition mode? It'll be called if the target function appears at top level of a WHERE or JOIN condition and any one of the function's arguments syntactically matches some column of an index. If there's multiple arguments matching the same index column, say index on "x" and we have "f(z, x, x)", you'll get one call and it will tell you about the first match (req->indexarg == 1 in this example). Sorting out what to do in such a case is your responsibility. If there's arguments matching more than one index column, say index declared on (x, y) and we have "f(x, y)", you'll get a separate call for each index column. Again, sorting out what to do for each one is your responsibility. 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). 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. > I have > created a table (foo) a geometry column (g) and an index (GIST on > foo(g)) and am running a query against foo using a noop function with > a support function bound to it. > The support function is called, twice, once in > T_SupportRequestSimplify mode and once in T_SupportRequestCost mode. What's the query look like exactly? The other two calls will occur anyway, but SupportRequestIndexCondition depends on the function call's placement. regards, tom lane