Re: Allowing extensions to supply operator-/function-specific info

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-27 23:50:50
Message-ID: BBB5F584-5036-4A11-B5FF-D30632EC9E1A@cleverelephant.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On Feb 27, 2019, at 3:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Variable SupportRequestCost is very exciting, but given that variable cost is usually driven by the complexity of arguments, what kind of argument is the SupportRequestCost call fed during the planning stage? Constant arguments are pretty straight forward, but what gets sent in when a column is one (or all) of the arguments?
>
> You'll see whatever is in the post-constant-folding parse tree. If it's a
> Const, you can look at the value. If it's a Var, you could perhaps look
> at the pg_statistic info for that column, though whether that would give
> you much of a leg up for cost estimation is hard to say. For any sort of
> expression, you're probably going to be reduced to using a default
> estimate. The core code generally doesn't try to be intelligent about
> anything beyond the Const and Var cases.

Actually, this is interesting, maybe there’s something to be done looking at the vertex density of the area under consideration… would require gathering extra stats, but could be useful (maybe, at some point feeding costs into plans has to degenerate into wankery…)

Another question:

I added three indexes to my test table:

CREATE INDEX foo_g_gist_x ON foo USING GIST (g);
CREATE INDEX foo_g_gist_nd_x ON foo USING GIST (g gist_geometry_ops);
CREATE INDEX foo_g_spgist_x ON foo USING SPGIST (g);

They all support the overlaps (&&) operator.

So, SupportRequestIndexCondition happens three times, and each time I say “yep, sure, you can construct an index condition by putting the && operator between left_arg and right_arg”.

How does the planner end up deciding on which index to *actually* use? The selectivity is the same, the operator is the same. I found that I got the ND GIST one first, then the SPGIST and finally the 2d GIST, which is unfortunate, because the 2D and SPGIST are almost certainly faster than the ND GIST.

In practice, most people will just have one spatial index at a time, but I still wonder?

P

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-02-28 00:24:11 Re: pgsql: Avoid creation of the free space map for small heap relations, t
Previous Message Tom Lane 2019-02-27 23:40:30 Re: Allowing extensions to supply operator-/function-specific info