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)
> 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(at)momjian(dot)us> http://momjian.us
+ It's impossible for everything to be true. +
In response to
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2012-07-26 16:16:29|
|Subject: Re: isolation check takes a long time|
|Previous:||From: Bruce Momjian||Date: 2012-07-26 16:06:27|
|Subject: Re: Using pg_upgrade on log-shipping standby servers|