Re: Read Uncommitted - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Read Uncommitted
Date
Msg-id 1211825199.8025.9.camel@huvostro
Whole thread Raw
In response to Re: Read Uncommitted  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Read Uncommitted  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2008-05-26 at 13:25 -0400, Tom Lane wrote:
> Hannu Krosing <hannu@krosing.net> writes:
> > On Mon, 2008-05-26 at 16:55 +0200, Peter Eisentraut wrote:
> >> If the data in a table never changes, why would VACUUM or HOT need to touch 
> >> it?  The use case isn't clear to me.
> 
> > I guess the use-case is about a long read-write transaction doing
> > read-only access to an update-only table and thus blocking vacuum on
> > other tables.
> 
> ... in which case the proposed kluge would result in unstable,
> unpredictable answers, so there is still no plausible use-case.

maybe it was meant as a super-power-user tool (and a big footgun) .

btw, when is a transaction id currently assigned to a transaction - when
INSERT/UPDATE/DELETE statement is first seen, or when data is actually
modified ?

that is when doing

INSERT INTO logtable 
SELECT current_timestamp, count(*) FROM really_huge_table;

will there be a transaction id for just the tiny moment the returned row
is inserted or for the whole count(*) time ?

----------------
Hannu




pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Proposal: temporal extension "period" data type
Next
From: Hannu Krosing
Date:
Subject: Re: Proposal: temporal extension "period" data type