Pavan Deolasee wrote:
> I was going to ask if we could implement indirect indexes as a separate
> IndexAM. But I re-read this thread and found that you'd in fact done it
> that way in the first version but then discarded it for performance
> reasons. Is there a merit in evaluating that path for indirect indexes
> again?
Yeah, that was my first approach, and I got it to work to some extent,
but the design felt wrong. What I wrote was "ibtree", an indirect
version of the btree AM. The performance wasn't any better than the
current one (though neither have been optimized at all), and the code
felt very ugly, probably because it was poking holes into abstraction
layers. I also had to duplicate all pg_amop/pg_amproc catalog entries,
etc.
Doing it as a new capability on top of an existing index AM feels much
more natural and seems to lead to a more reasonable model, all things
considered.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services