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

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Zeugswetter Andreas DCP SDDate: 2006-06-27 08:57:15
Subject: Re: [PATCHES] Non-transactional pg_class, try 2
Previous:From: Kim BisgaardDate: 2006-06-27 08:46:20
Subject: Re: Table clustering idea

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