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. +
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 |