Alexander Korotkov wrote:
> Hi!
>
> Thank you for review!
So. Before this version of the patch was posted in Nov 4th 2015, both
Tom and Heikki had said essentially "CREATE ACCESS METHOD is worthless,
let's pursue this stuff without those commands".
http://www.postgresql.org/message-id/54730DFD.2060703@vmware.com (Nov 2014)
http://www.postgresql.org/message-id/26822.1414516012@sss.pgh.pa.us (Oct 2014)
And then Alexander posted this version, without any discussion that
evidenced that those old objections were overridden. What happened
here? Did somebody discuss this in unarchived meetings? If so, it
would be good to know about that in this thread.
I noticed this state of affairs because I started reading the complete
thread in order to verify whether a consensus had been reached regarding
the move of IndexQualInfo and GenericCosts to selfuncs.h. But I only
see that Jim Nasby mentioned it and Alexander said "yes they move";
nothing else. The reason for raising this is that, according to
Alexander, new index AMs will want to use those structs; but current
index AMs only include index_selfuncs.h, and none of them includes
selfuncs.h, so it seems completely wrong to be importing all the planner
knowledge embodied in selfuncs.h into extension index AMs.
One observation is that the bloom AM patch (0003 of this series) uses
GenericCosts but not IndexQualInfo. But btcostestimate() and
gincostestimate() both use IndexQualInfo, so other AMs might well want
to use it too.
We could move GenericCosts and the prototype for genericcostestimate()
to index_selfuncs.h; that much is pretty reasonable. But I'm not sure
what to do about IndexQualInfo. We could just add forward struct
declarations for RestrictInfo and Node to index_selfuncs.h. But then
the extension code is going to have to import the includes were those
are defined anyway. Certainly it seems that deconstruct_indexquals()
(which returns a list of IndexQualInfo) is going to be needed by
extension index AMs, at least ...
I've made a few edits to the patch already, but I need to do some more
testing. Particularly I would like to understand the relcache issues to
figure out whether the current one is right.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services