Re: Read Uncommitted
От | Hannu Krosing |
---|---|
Тема | Re: Read Uncommitted |
Дата | |
Msg-id | 1211825199.8025.9.camel@huvostro обсуждение исходный текст |
Ответ на | Re: Read Uncommitted (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Read Uncommitted
|
Список | 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 по дате отправления: