> > Also, more work would be required for every update. Right now an
> > update requires a B-tree insert for each index. With this change,
> > every update would require an additional B-tree lookup and write for
> > each index. That would require on average a bit less than one
> > additional block write per index. That's a lot.
> >
> > In exchange, certain queries would become faster. Specifically, any
> > query which only needed the information found in an index would become
> > faster. Each such query would save on average a bit less than one
> > additional block read per value found in the index. But since the
> > indices would be less efficient, some of the advantage would be lost
> > due to extra block reads of the index.
> >
> > What you are suggesting seems possible, but it does not seem to be
> > obviously better.
>
> It may not be as obvious as it first seemed to me, but I bet there are
> certain databases out there that have just the right pattern of data
> that would benefit from this. I suppose this is something that
> compilers have tried to balance all along. Maybe there could be a
> different type of index that could be manually added by admins who
> wanted to fiddle around with their database.
If you want performance options, MySQL is the champ. We usually require
a clear reason to give users more options because too many options can
be quite confusing. It is more a design philosophy.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026