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

Re: PostgreSQL clustering VS MySQL clustering

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
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 10:42:47
Message-ID: 1106649767.5790.18.camel@fuji.krosing.net (view raw or flat)
Thread:
Lists: pgsql-performance
Ühel kenal päeval (esmaspäev, 24. jaanuar 2005, 11:52+0900), kirjutas
Tatsuo Ishii:
> > 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 ?


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>

In response to

Responses

pgsql-performance by date

Next:From: Steve PoeDate: 2005-01-25 11:57:24
Subject: Ideal disk setup for Postgresql 7.4?
Previous:From: Antony PaulDate: 2005-01-25 10:09:56
Subject: Re: How to boost performance of ilike queries ?

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