Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group