>>> On Fri, Nov 16, 2007 at 4:01 PM, in message
<b42b73150711161401p13e93e4dn19bc8388a2da9208(at)mail(dot)gmail(dot)com>, "Merlin Moncure"
<mmoncure(at)gmail(dot)com> wrote:
> On Nov 16, 2007 10:56 AM, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info> wrote:
>> On Wed, 2007-11-14 at 17:46 -0500, Tom Lane wrote:
>> > Russell Smith <mr-russ(at)pws(dot)com(dot)au> writes:
>> > > It is possible that analyze is not getting the number of dead rows right?
>> >
>> > Hah, I think you are on to something. ANALYZE is telling the truth
>> > about how many "dead" rows it saw, but its notion of "dead" is "not good
>> > according to SnapshotNow". Thus, rows inserted by a not-yet-committed
>> > transaction would be counted as dead. So if these are background
>> > auto-analyzes being done in parallel with inserting transactions that
>> > run for awhile, seeing a few not-yet-committed rows would be
>> > unsurprising.
>> >
>> > I wonder if that is worth fixing? I'm not especially concerned about
>> > the cosmetic aspect of it, but if we mistakenly launch an autovacuum
>> > on the strength of an inflated estimate of dead rows, that could be
>> > costly.
>>
>> Sounds to me like that could result in autovacuum kicking off while
>> doing large data loads. This sounds suspiciously like problem someone
>> on -novice was having - tripping over a windows autovac bug while doing
>> a data load
>>
>> http://archives.postgresql.org/pgsql-novice/2007-11/msg00025.php
>
> I am almost 100% I've seen this behavior in the field...
I know I've seen bulk loads go significantly faster with autovacuum
turned off. It always seemed like a bigger difference than what the
ANALYZE would cause. I bet this explains it.
-Kevin