Re: [PATCHES] [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-02-04 Thread Tom Lane
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

Re: [PATCHES] [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-02-03 Thread Heikki Linnakangas
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"

Re: [PATCHES] [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-02-01 Thread Bruce Momjian
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: > >

Re: [PATCHES] [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-02-01 Thread Tom Lane
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

Re: [PATCHES] [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-02-01 Thread Heikki Linnakangas
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

[PATCHES] Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-01-31 Thread Bruce Momjian
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

Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-01-17 Thread Gregory Stark
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

Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-01-16 Thread Heikki Linnakangas
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

Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-01-16 Thread Tom Lane
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

[pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-01-16 Thread Heikki Linnakangas
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