On 3/9/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
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.
Couldn't they (or at least one of them) become visible due to
SAVEPOINT rollback?
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
Mike Rylander
[EMAIL PROTECTED]
GPLS -- PINES Development
Database Developer
http://open-ils.org
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
