> >>> > I've been attempting to port applications from Pervasive SQL to PG. > >>> > Pervasive is interesting because it runs on top of btrieve. This allow > >>> > legacy apps > >>> > and SQL systems to co-exist. It's quirky and buggy, but it's better than PG > >>> > because it can do the following. > >>> > > >>> > > >>> > 1. Have more than 7 fields on a btree index > >>> > >>> We have never understood why someone would want an index with more than > >>> seven columns. > > Legacy apps, Bruce. Sometimes you come across tables with ten fields in the index. I'm > working on a (fairly specialised) system now where the primary key of one of the tables has > twenty-four fields in it. It is a summary table, and probably not the best design, but that's the > way it is, and I have to live with it. Unfortunately, because we don't have a database that can > have that many fields in a key, we have to construct manual indices in code. Even Oracle > (which is what we are using) only goes up to about 21 or something. However, if you are > going to summarise heavily, then the number of fields in your primary key can get quite large. > > How difficult would it be to make the number of fields in an index unlimited (or arbitrarily large). > Perhaps there could be a compile-time variable which is defaulted to 7, but which can be > increased using the configure script (./configure --with-index-fields=24). I realise that there > are performance issues, but that's a trade off that only the system designers can make. > > MikeA... I forgot to add that a trigger to check for uniqueness on this table would be quite slow (especially without the required index), as about two million rows are being added daily. MikeA...
