On Sun, Nov 28, 2010 at 6:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> After our recent conversation >> about KNNGIST, it occurred to me to wonder whether there's really any >> point in pretending that a user can usefully add an AM, both due to >> hard-wired planner knowledge and due to lack of any sort of extensible >> XLOG support. If not, we could potentially turn pg_am into a >> hardcoded lookup table rather than a modifiable catalog, which would >> also likely be faster; and perhaps reference AMs elsewhere with >> characters rather than OIDs. But even if this were judged a sensible >> thing to do I'm not very sure that even a purpose-built synthetic >> benchmark would be able to measure the speedup. > > Well, the lack of extensible XLOG support is definitely a big handicap > to building a *production* index AM as an add-on. But it's not such a > handicap for development.
Realistically, it's hard for me to imagine that anyone would go to the trouble of building it as a loadable module first and then converting it to part of core later on. That'd hardly be less work. > And I don't believe that the planner is > hardwired in any way that doesn't allow new index types. GIST and GIN > have both been added successfully without kluging the planner. We have 9 boolean flags to indicate the capabilities (or lack thereof) of AMs, and we only have 4 AMs. It seems altogether plausible to assume that the next AM we add could require flags 10 and 11. Heck, I think KNNGIST is going to require another flag... which will likely never be set for any AM other than GIST. > It does > know a lot more about btree than other index types, but that doesn't > mean you can't add a new index type that doesn't behave like btree; > that's more reflective of where development effort has been spent. > > So I would consider the above idea a step backwards, and I doubt it > would save anything meaningful anyway. That latter point, as far as I'm concerned, is the real nail in the coffin. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
