Re: PostgreSQL clustering VS MySQL clustering

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, 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-24 01:56:25
Message-ID: 1106531786.5790.9.camel@fuji.krosing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Ühel kenal päeval (pühapäev, 23. jaanuar 2005, 15:40-0500), kirjutas Tom
Lane:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Changing the idea slightly might be better: if a row update would cause
> > a block split, then if there is more than one row version then we vacuum
> > the whole block first, then re-attempt the update.
>
> "Block split"? I think you are confusing tables with indexes.
>
> Chasing down prior versions of the same row is not very practical
> anyway, since there is no direct way to find them.
>
> One possibility is, if you tried to insert a row on a given page but
> there's not room, to look through the other rows on the same page to see
> if any are deletable (xmax below the GlobalXmin event horizon). This
> strikes me as a fairly expensive operation though, especially when you
> take into account the need to get rid of their index entries first.

Why is removing index entries essential ?

In pg yuo always have to visit data page, so finding the wrong tuple
there could just produce the same result as deleted tuple (which in this
case it actually is). The cleaning of index entries could be left to the
real vacuum.

--
Hannu Krosing <hannu(at)tm(dot)ee>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tatsuo Ishii 2005-01-24 02:52:44 Re: PostgreSQL clustering VS MySQL clustering
Previous Message Tatsuo Ishii 2005-01-24 01:30:33 Re: PostgreSQL clustering VS MySQL clustering