Am Montag, 26. Mai 2008 schrieb Simon Riggs:
> At the moment, a long running SQL Statement can prevent xmin moving
> forward, which can result in VACUUM and HOT not being able to remove row
> versions effectively. My proposal is that a Read Uncommitted transaction
> would not prevent row removal, which then offers no guarantee that the
> "correct" answer would be returned. Which is *exactly* what that
> transaction isolation level was designed for.
>
> In many cases, an application designer may be able to tell that a
> particular query will always return the correct answer. For example, we
> may query against data which is known not to change, even though other
> data in the same database cluster may be subject to frequent change.
> e.g. queries against large insert-only tables.
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.
