Re: profiling connection overhead

Robert Haas <robertmhaas(at)gmail(dot)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