Re: Feature request for adoptive indexes

>
> 4 columns: 106 ms
> 6 columns: 109 ms
>
> So there's like 3% difference between the two cases, and even that might
> be just noise. This is consistent with the two indexes being about the
> same size.
>
I also don't think we can get great speedup in the mentioned case, so it is
not urgently needed of course. My point is that it is just nice to have a
multicolumn index constructed on stacked trees constructed on separate
columns, not on the index tuples as a whole thing. At least there is a
benefit of sparing shared memory if we don't need to cache index tuples of
several similar indexes, instead caching one "compound index". So if
someone wants to propose this thing I'd support it provided problems with
concurrency, which were mentioned by Peter are solved.

These problems could be appear easy though, as we have index tuples
constructed in a similar way as heap tuples. Maybe it could be easier if we
had another heap am, which stored separate attributes (if so it could be
useful as a better JSON storage method than we have today).

--
Best regards,
Pavel Borisov

Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>