Does auto-analyze work on dirty writes? (was: Re: [HACKERS] Slow count(*) again...) - Mailing list pgsql-performance

From Mark Mielke
Subject Does auto-analyze work on dirty writes? (was: Re: [HACKERS] Slow count(*) again...)
Date
Msg-id 4D4B7317.3070803@mark.mielke.cc
Whole thread Raw
In response to Re: [HACKERS] Slow count(*) again...  (Conor Walsh <ctw@adverb.ly>)
Responses Re: Does auto-analyze work on dirty writes? (was: Re: [HACKERS] Slow count(*) again...)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On 02/03/2011 09:45 PM, Conor Walsh wrote:
> My understanding is that auto-analyze will fire only after my
> transaction is completed, because it is a seperate daemon.  If I do
> like so:
>
> BEGIN;
> COPY ...;
> -- Dangerously un-analyzed
> SELECT complicated-stuff ...;
> END;
>
> Auto-analyze does not benefit me, or might not because it won't fire
> often enough.  I agree that analyze is very fast, and it often seems
> to me like the cost/benefit ratio suggests making auto-analyze even
> more aggressive.

The count discussion is boring. Nothing new there. But auto-analyze on
dirty writes does interest me. :-)

My understanding is:

1) Background daemon wakes up and checks whether a number of changes
have happened to the database, irrelevant of transaction boundaries.

2) Background daemon analyzes a percentage of rows in the database for
statistical data, irrelevant of row visibility.

3) Analyze is important for both visible rows and invisible rows, as
plan execution is impacted by invisible rows. As long as they are part
of the table, they may impact the queries performed against the table.

4) It doesn't matter if the invisible rows are invisible because they
are not yet committed, or because they are not yet vacuumed.

Would somebody in the know please confirm the above understanding for my
own piece of mind?

Thanks,
mark

--
Mark Mielke<mark@mielke.cc>


pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: [HACKERS] Slow count(*) again...
Next
From: Scott Marlowe
Date:
Subject: Re: [HACKERS] Slow count(*) again...