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