> On Feb 5, 2019, at 11:07 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Paul Ramsey <pram...@cleverelephant.ca> writes:
>> Hokay… I’ve read through the patch set, applied it and built it, all works.
>> Am starting to try a test implementation in PostGIS land. Robert’s comment
>> about “PostgreSQL magic” is ringing through my head ... Nodes and Ops and
>> Exprs, oh my! What ever doesn’t kill me only makes me stronger, right? :)
>
> Thanks for looking at it! I think you are going to have some issues
> with identifying the operators to use in PostGIS, since unlike the
> core code you can't assume fixed OIDs for anything. The other thread
> I'd started has some ideas about fixing that, and I hope to get
> something into v12 for it, but it's not done yet.
>
> For testing purposes it might be enough to look up your index opfamilies
> by name, though I'd not really recommend that as a production answer.
>
> You're also kind of jumping the gun on the documentation ;-). I need
> to write a lot more in supportnodes.h about how to use the IndexCondition
> callback, but the basic idea is to generate a list of OpExprs (at least
> that'd be the normal case) that represent a directly-indexable condition.
> It's entirely up to you to ensure that they *are* indexable conditions,
> ie with an operator that belongs to the index's opfamily, index key on
> the left, pseudoconstant value on the right. The sample code that's
> there now for LIKE/regex kind of punts on the last point: since it
> can only do anything useful with a simple Const pattern, it doesn't
> have to think hard about what's acceptable. If you want to allow
> non-simple-Const RHS then you need to reject volatile functions and
> Vars of the indexed relation. I was thinking of exposing a function
> specifically to make that test, rather than requiring extensions to
> copy the logic, but I didn't do it yet.
<fear>
So just a meta-comment, this is all very cool and I can see how it will help
out things like selectivity estimation and tuple return estimation for unnest()
and generate_series() and even how I could eventually do some dynamic costing
for some functions, but it’s getting very deep and far from our proximate
problem which was just we were having trouble increasing the costs on our
functions so we could get more frequent parallelization.
We’re going to have a net complexity increase in our code base, because we’ll
be maintaining this new approach alongside the old one for about 5 years until
v12 becomes our oldest supported PostgreSQL.
And this paragraph above (excuse my ignorance) worries me that I might have a
bunch of use patterns I now have to explicitly predict will happen and support
that I might have gotten “for free” with the old dumbass inlining approach.
The only thing that will get more efficient for us, I think, will be
ST_DWithin, which can pick the correct index op to use instead of supplying
both of them. (Maybe? I think I’ll end up writing a bunch of logic which I
previously got “for free” to (a) find which indexes are available? (b) if I
have an index on *both* columns, check the selectivity of 'expand(b) && a' vs
'b && expand(a)’ and (c) build up an appropriate new structure that
incorporates the index *and* the expand() function call wrapper on the
appropriate side.
</fear>
Anyways, once I have done an implementation it will probably appear less
daunting.
P
>
> Anyway, happy to help if you have questions, just ask.
>
> regards, tom lane
