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. 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. 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
