Re: Changing SQL Inlining Behaviour (or...?) - Mailing list pgsql-hackers

> On Feb 5, 2019, at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Paul Ramsey <pramsey@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
inPostGIS 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
tuplereturn estimation for unnest() and generate_series() and even how I could eventually do some dynamic costing for
somefunctions, but it’s getting very deep and far from our proximate problem which was just we were having trouble
increasingthe 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
alongsidethe 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
explicitlypredict 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
useinstead 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