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>
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 |