On Tue, Jul 17, 2012 at 06:00:37PM +0100, Simon Riggs wrote:
> > Either way the data in "c" and "d" are IN THE INDEX otherwise in neither
> > case could the data values be returned while strictly querying the index.
> >
> > So the question that needs to be asked is what kind of performance increase
> > can be had during DML (insert/update) statements and whether those gains are
> > worth pursuing. Since these other engines appear to allow both cases you
> > should be able to get at least a partial idea of the performance gains
> > between "index (a,b,c,d)" and "index (a,b) covering (c,d)".
>
> There is a use case, already discussed, whereby that is useful for
> create unique index on foo (a,b) covering (c,d)
>
> but there really isn't any functional difference between
> create index on foo (a,b) covering (c,d)
>
> and
> create index on foo (a,b,c,d)
>
> There is a potential performance impact. But as Tom says, that might
> even be negative if it is actually measurable.
So, do we want a TODO item about adding columns to a unique index that
will not be used for uniqueness checks?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +