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

Re: vacuum, performance, and MVCC

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Hannu Krosing <hannu(at)skype(dot)net>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Mark Woodward <pgsql(at)mohawksoft(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)acm(dot)org>
Subject: Re: vacuum, performance, and MVCC
Date: 2006-06-29 15:27:07
Message-ID: 200606291527.k5TFR7V03004@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Hannu Krosing wrote:
> > > But we still have to think about similar cases (index entries pointing
> > > inside CITC chains), unless we plan to disallow adding indexes to
> > > tables.
> > 
> > CREATE INDEX has to undo any chains where the new indexed columns change
> > in the chain, and add index entries to remove the chain.
> 
> Yes, that would be the most straightforward solution.
> 
> It could be better in some cases, if we could avoid adding entries to
> other indexes. Maybe we can just reset some flags, so that some SITC ops
> like finding tuples by the CITC index pointer still work while adding
> new entries wont. 
> 
> But it will be tricky to make this work for bitmap index scans. 
> 
> So yes, index build is a slop operation anyway, so making it even a
> little slower is probably not a big problem. And most CITC chains will
> have only one visible row at a time, this will probably not be a big
> issue. 

Consider that index scans coming from different indexes have to span the
same SITC.  I see no clean way to avoid making all the indexes
consistent, and as you said, CREATE INDEX isn't a frequent operation.

-- 
  Bruce Momjian   bruce(at)momjian(dot)us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-hackers by date

Next:From: Greg StarkDate: 2006-06-29 15:54:43
Subject: Re: [GENERAL] UUID's as primary keys
Previous:From: Martijn van OosterhoutDate: 2006-06-29 15:07:28
Subject: Re: [GENERAL] UUID's as primary keys

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