From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Recalculating OldestXmin in a long-running vacuum |
Date: | 2007-01-16 18:21:34 |
Message-ID: | 45AD17AE.5050603@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> 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 FreezeLimit.
> 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 difference there, but if
you're using a big cost delay, it could make quite a difference for such
a simple thing.
> The procarray.c change scares me as well; I'm pretty sure the original
> coding was intentional.
Well, it didn't make much difference before, since OldestXmin was always
calculated early in the transaction.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2007-01-16 18:45:37 | Re: Autovacuum improvements |
Previous Message | Tom Lane | 2007-01-16 16:31:26 | Re: Recalculating OldestXmin in a long-running vacuum |