Re: profiling connection overhead

On Sun, Nov 28, 2010 at 6:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

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