> On Oct 26, 2021, at 1:43 PM, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:
>
> I'm still rather skeptical about it - for such feature to be useful the prefix columns must not be very selective,
i.e.the posting trees are expected to be fairly large (e.g. 5-7k rows). It pretty much has to to require multiple
(many)index pages, in order for the "larger" btree index to be slower. And at that point I'd expect the extra overhead
tobe worse than simply defining multiple simple indexes.
For three separate indexes, an update or delete of a single row in the indexed table would surely require changing at
leastthree pages in the indexes. For some as-yet-ill-defined combined index type, perhaps the three entries in the
indexwould fall on the same index page often enough to reduce the I/O cost of the action? This is all hard to
contemplatewithout a more precise description of the index algorithm.
Perhaps the OP might want to cite a paper describing a particular index algorithm for us to review?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company