Tom Lane [EMAIL PROTECTED] wrote:
This is a stand-alone patch for aggressive freezing. I'll propose
to use OldestXmin instead of FreezeLimit as the freeze threshold
in the circumstances below:
I think it's a really bad idea to freeze that aggressively under any
circumstances except
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I don't think we can supply such a historical database functionality here,
because we can guarantee it just only for INSERTed tuples even if we pay
attention. We've already enabled autovacuum as default, so that we cannot
predict when the next
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I think it's a really bad idea to freeze that aggressively under any
circumstances except being told to (ie, VACUUM FREEZE). When you
freeze, you lose history information that might be needed later --- for
forensic
Gregory Stark [EMAIL PROTECTED] wrote:
The hoped for gain here is that vacuum finds fewer pages with tuples that
exceed vacuum_freeze_min_age? That seems useful though vacuum is still going
to have to read every page and I suspect most of the writes pertain to dead
tuples, not freezing
Tom Lane [EMAIL PROTECTED] wrote:
I said nothing about expired tuples. The point of not freezing is to
preserve information about the insertion time of live tuples.
I don't know what good it will do -- for debugging?
Why don't you use CURRENT_TIMESTAMP?
And your
test case is
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
I said nothing about expired tuples. The point of not freezing is to
preserve information about the insertion time of live tuples.
I don't know what good it will do -- for debugging?
Exactly. As an example, I've
Jim C. Nasby [EMAIL PROTECTED] wrote:
* Aggressive freezing
we will use OldestXmin as the threshold to freeze tuples in
dirty pages or pages that have some dead tuples. Or, many UNFROZEN
pages still remain after vacuum and they will cost us in the next
vacuum preventing XID wraparound.
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
This is a stand-alone patch for aggressive freezing. I'll propose
to use OldestXmin instead of FreezeLimit as the freeze threshold
in the circumstances below:
I think it's a really bad idea to freeze that aggressively under any
circumstances except
Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
This is a stand-alone patch for aggressive freezing. I'll propose
to use OldestXmin instead of FreezeLimit as the freeze threshold
in the circumstances below:
I think it's a really bad idea to freeze that aggressively under any
Florian G. Pflug wrote:
There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit
would be calculated as
GetOldestXmin() - vacuum_freeze_limit
We already have that. It's called vacuum_freeze_min_age, and the default
is 100 million transactions.
IIRC we added it late in the 8.2
Heikki Linnakangas wrote:
Florian G. Pflug wrote:
There could be a GUC vacuum_freeze_limit, and the actual FreezeLimit
would be calculated as
GetOldestXmin() - vacuum_freeze_limit
We already have that. It's called vacuum_freeze_min_age, and the default
is 100 million transactions.
IIRC we
11 matches
Mail list logo