Re: CLUSTER and MVCC

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLUSTER and MVCC
Date: 2007-03-09 15:40:23
Message-ID: 45F17FE7.4000706@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas wrote:
> Csaba Nagy wrote:
>> On Fri, 2007-03-09 at 14:00, Alvaro Herrera wrote:
>>> But I'm not really seeing the problem here. Why isn't Csaba's problem
>>> fixed by the fact that HOT reduces the number of dead tuples in the
>>> first place? If it does, then he no longer needs the CLUSTER
>>> workaround, or at least, he needs it to a much lesser extent.
>>
>> Is this actually true in the case of HOT + long running transactions ? I
>> was supposing HOT has the same problems in the presence of long running
>> transactions...
>
> It does, HOT won't help you here. A long-running transaction is just as
> much of a problem with HOT as without. Besides, I don't recall that
> you're doing updates in the first place.

Couldn't HOT in principle deal with this? Let's say you have two long-running
transactions, which see row versions A and D. While those transactions
are running, the row is constantly updated, leading to row versions B, C (before
the second long-running transaction started), D, E, F, ... Z.
Now, the versions B,C,E,F,...Z could be removed by HOT or vacuum, because they
are not currently visible, nor will they ever become visible because they are
already deleted.

greetings, Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2007-03-09 15:41:42 Re: Calculated view fields (8.1 != 8.2)
Previous Message Florian G. Pflug 2007-03-09 15:34:04 Re: Calculated view fields (8.1 != 8.2)