Re: VACUUM/ANALYZE counting of in-doubt tuples - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: VACUUM/ANALYZE counting of in-doubt tuples
Date
Msg-id 47442AD5.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to Re: VACUUM/ANALYZE counting of in-doubt tuples  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>> On Wed, Nov 21, 2007 at 12:32 PM, in message <15089.1195669979@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> Has this issue been a real problem?  If so, probably we should consider
>> adjusting ANALYZE for 8.3 per your proposal.
>
> I'm not sure.  Upthread, two or three people said they thought they'd
> seen autovac launching vacuums against tables during bulk inserts.
> However, that could only happen if there were already a reason to launch
> an auto-analyze (which could misreport dead tuples and thus trigger a
> subsequent auto-vacuum), and in typical bulk load situations I don't see
> why that would be very likely to happen.
We had been in the habit of throwing a commit into our bulk loads
periodically (say, every 10,000 or 100,000 rows.  This was because
our prior database product needed to keep the entire transaction
image in a fixed-size transaction log until commit; if we didn't
commit now and then, the whole thing locked up and died.  I'm not
sure I've seen the behavior since we realized it was just an old
habit and went to a single transaction per table.
> I'm fine with leaving the whole issue for 8.4.
Perhaps a comment somewhere in the documentation regarding the
above should go into releases where this technique can be costly?
Suggesting a single transaction or suspension of autovacuum?
-Kevin




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: plperl failure on OS X 10.5(.1)
Next
From: "Guillaume Smet"
Date:
Subject: 8.3devel slower than 8.2 under read-only load