Re: Covering Indexes

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: David Johnston <polobo(at)yahoo(dot)com>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Covering Indexes
Date: 2012-07-26 16:13:47
Message-ID: 20120726161347.GK21271@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-07-26 16:16:29 Re: isolation check takes a long time
Previous Message Bruce Momjian 2012-07-26 16:06:27 Re: Using pg_upgrade on log-shipping standby servers