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
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"
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:
>
>
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" scans:1 page
Bruce Momjian wrote:
Have you gotten performance numbers on this yet?
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.sto
Have you gotten performance numbers on this yet?
---
Gregory Stark wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>
> > Tom Lane wrote:
> >
> > > In any case I'd like to see some evidence of significant real-world
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
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 F
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 b
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 r
10 matches
Mail list logo