I might need to work with relatively large (non-clustered) index keys (between 1KB to 4KB). I found that Spanner and DB2 support 8KB index-key size, MSSQL allows 1.7KB and Postgress around 2.6KB (1/3 of the Postgress' block size). While reading other posts, I found that mostly one can avoid using such large keys, and I will try to think whether I can do so, but I have a few questions in case I do not succeed to avoid it in all cases.
I do not know what data structures are used to implement indexes in the mentioned systems (except of Postgress of course). I am well familiar with B+Trees, and it seems hard to efficiently save such large keys as the B+Tree's inner nodes pivots, since the branching factor will be too small and thus any read/write will cost too many IOs. I believe that compression methods might work, but many compression methods (like using hash function which does not preserve order) might defect the key's order which eliminates the possibility to use the index for range queries. So, I would be glad for any documentation or information about the DBMS's index implementations, especially anything that relates to relatively large keys. (I have already read the manuals, but they do not talk about how they actually work with large keys).
In addition, I would like to know whether those DBMS are indeed efficient when working with keys which are close to stated index-key size limits? I have no previous experience working with large index-keys, and any information and past experience (dos and dont's) would be really appreciated.