Re: Weird indices

> > 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