Paul Ramsey <pram...@cleverelephant.ca> writes:
> 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.
Sure, but you need to think bigger about what problem you're solving ;-).
There was no chance that we were going to back-patch that inlining rule
change hack, so none of this would provide you an opportunity to do better
in existing releases anyway. With a bit more work --- and, honestly,
I think it should not end up being more than ~100 lines of C code
for you, else I've done something wrong --- we can move the goalposts
quite a long way in v12.
> 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.
No, I don't think so. The only aspect of that that the support function
is responsible for is verifying that the currently-looked-at index is
applicable, which boils down to checking that the index opfamily is
what you're expecting. As I mentioned, the core code is just doing that
by testing for compiled-in OIDs, but extensions are going to have to
work a little harder because their opfamilies haven't got fixed OIDs.
Roughly speaking, what you've got to do is
* verify the index's opfamily OID (OK, some uncertainty
remains about best way to do that)
* find out operator OID for && --- if nothing else,
get_opfamily_member() will serve for that, once you've
got the opfamily OID
* build index operator expression with make_opclause().
Figuring out the rest is the domain of the core code. If there
are decisions to be made, it'd boil down to whether you've attached
good selectivity estimators to the index operators ... but if you
don't have that then I doubt you were getting good results before.
Anyway, as I said, I'm plenty happy to help. I'd like to see how
this code turns out in PostGIS; if it's really all that complicated
then I need to spend some effort on adding infrastructure to make
it simpler.
regards, tom lane
