Re: vacuum, performance, and MVCC

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: vacuum, performance, and MVCC
Date: 2006-06-27 08:48:06
Message-ID: 1151398087.3516.18.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ühel kenal päeval, E, 2006-06-26 kell 11:31, kirjutas Bruce Momjian:
> Hannu Krosing wrote:
> > > > pass 3: clean heap based on ctid from pass 1
> > > >
> > > > If yo do it this way, you dont need to invent new data structures to
> > > > pass extra info about CITC internals to passes 2 and 3
> > > >
> > > > On more thing - when should free space map be notified about free space
> > > > in pages with CITC chains ?
> > >
> > > Uh, well, I am thinking we only free CITC space when we are going to use
> > > it for an UPDATE, rather than free things while doing an operation. It
> > > is good to keep the cleanup overhead out of the main path as much as
> > > possible.
> >
> > So vacuum should only remove dead CITC chains and leave the ones with
> > live tuples to CITC internal use ?
>
> Yes, it has to. What else would it do? Add index entries?

No, clean out the dead part.

But this would probably add the page to FSM - do we want that.

Also, this cleaning should probably be done at pass1, so we dont have to
carry the ctids of tuples which have no index entries around to passes 2
and 3 . This has the downside of possibly writing the heap page twice,
so maybe we dont want it.

> > That would also suggest that pages having live CITC chains and less than
> > N% of free space should mot be reported to FSM.
>
> Parts of the CITC that are not visible can be used for free space by
> vacuum, but the visible part is left alone.
>
--
----------------
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 Zeugswetter Andreas DCP SD 2006-06-27 08:57:15 Re: [PATCHES] Non-transactional pg_class, try 2
Previous Message Kim Bisgaard 2006-06-27 08:46:20 Re: Table clustering idea