Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW I've got serious reservations about whether this bit is safe:
+ /* The table could've grown since vacuum started, and
there
+* might already be dead tuples on the new pages. Catch
them
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I have two runs of DBT-2, one with the patch and one without.
Patched:
autovac public.stock scans:1 pages:1285990(-0)
tuples:25303056(-2671265) CPU 95.22s/38.02u sec elapsed 10351.17 sec
Unpatched:
autovac public.stock
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
In any case I'd like to see some evidence of significant real-world
benefit before adding such a conceptual wart ...
I've asked our testers to do a TPC-C run with and without the
patch. I'm not expecting it to make a huge
Hi,
It seems to me that we could easily reclaim a bit more dead tuples in a
vacuum by recalculating the OldestXmin every now and then. In a large
table with a constant stream of updates/deletes and concurrent vacuums,
this could make a big difference.
With the attached patch, OldestXmin is
Heikki Linnakangas [EMAIL PROTECTED] writes:
It seems to me that we could easily reclaim a bit more dead tuples in a
vacuum by recalculating the OldestXmin every now and then.
Doesn't this break relfrozenxid maintenance? In any case I'd like to
see some evidence of significant real-world
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
It seems to me that we could easily reclaim a bit more dead tuples in a
vacuum by recalculating the OldestXmin every now and then.
Doesn't this break relfrozenxid maintenance?
Not AFAICS. relfrozenxid is nowadays updated with
