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,

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

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to