Thread: RE: Limitations

RE: Limitations

From
"Ansley, Michael"
Date:
> >>> > 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...