Re: vacuum, performance, and MVCC

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
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 07:30:30
Message-ID: 1151566230.2897.21.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ühel kenal päeval, T, 2006-06-27 kell 12:16, kirjutas Bruce Momjian:
> Hannu Krosing wrote:
> > ?hel kenal p?eval, T, 2006-06-27 kell 10:38, kirjutas Hannu Krosing:
> > > ?hel kenal p?eval, E, 2006-06-26 kell 23:08, kirjutas Bruce Momjian:
> > > > Jim C. Nasby wrote:
> > > > > On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote:
> > > > > >
> > > > > > It is certainly possible to do what you are suggesting, that is have two
> > > > > > index entries point to same chain head, and have the index access
> > > > > > routines figure out if the index qualifications still hold, but that
> > > > > > seems like a lot of overhead.
> > >
> > > I think Jim meant not 2 pointing to the same head, but 2 pointing into
> > > the same chain. Say we have table with (id serial, ts timestamp) where
> > > ts changes at each update and id does not.
> > >
> > > So after 3 updates on one page we have one CITC/ITPC head with pointers
> > > from both indexes and two follow-up tuples with pointers from only ts
> > > index.
> > >
> > > The problem with this setup is, that we can't reuse any of those
> > > follow-up tuples without index cleanup.
> >
> > 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.

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-06-29 08:39:27 Re: [HACKERS] Non-transactional pg_class, try 2
Previous Message Sandeep Jakkaraju(Navolve) 2006-06-29 07:29:20 Compilatiuon of source code for windows