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