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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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. +

Browse pgsql-hackers by date

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