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

Re: PostgreSQL clustering VS MySQL clustering

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: hannu(at)tm(dot)ee
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, marty(at)outputservices(dot)com, herve(at)elma(dot)fr,pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL clustering VS MySQL clustering
Date: 2005-01-25 14:19:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
> > > Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > > > Probably VACUUM works well for small to medium size tables, but not
> > > > for huge ones. I'm considering about to implement "on the spot
> > > > salvaging dead tuples".
> > > 
> > > That's impossible on its face, except for the special case where the
> > > same transaction inserts and deletes a tuple.  In all other cases, the
> > > transaction deleting a tuple cannot know whether it will commit.
> > 
> > Of course. We need to keep a list of such that tuples until commit or
> > abort.
> what about other transactions, which may have started before current one
> and be still running when current one commites ?

Then dead tuples should be left. Perhaps in this case we could
register them in FSM or whatever for later processing.
Tatsuo Ishii

> I once proposed an extra parameter added to VACUUM FULL which determines
> how much free space to leave in each page vacuumed. If there were room
> the new tuple could be placed near the old one in most cases and thus
> avoid lots of disk head movement when updating huge tables in one go.
> ------------
> Hannu Krosing <hannu(at)tm(dot)ee>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?

In response to

pgsql-performance by date

Next:From: Don DrakeDate: 2005-01-25 15:10:50
Subject: Postgres stopped running (shmget failed)
Previous:From: Stephan SzaboDate: 2005-01-25 14:01:25
Subject: Re: How to boost performance of ilike queries ?

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