Re: Analyze on large changes... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Analyze on large changes...
Date
Msg-id 7190.1020264821@sss.pgh.pa.us
Whole thread Raw
In response to Analyze on large changes...  ("Rod Taylor" <rbt@zort.ca>)
Responses Re: Analyze on large changes...
Re: Analyze on large changes...
List pgsql-hackers
"Rod Taylor" <rbt@zort.ca> writes:
> Since dead, or yet to be visible tuples affect the plan that should be
> taken (until vacuum anyway) are these numbers reflected in the stats
> anywhere?

Analyze just uses SnapshotNow visibility rules, so it sees the same set
of tuples that you would see if you did a SELECT.

It might be interesting to try to estimate the fraction of dead tuples
in the table, though I'm not sure quite how to fold that into the cost
estimates.  [ thinks... ]  Actually I think we might just be
double-counting if we did.  The dead tuples surely should not count as
part of the number of returned rows.  We already do account for the
I/O effort to read them (because I/O is estimated based on the total
number of blocks in the table, which will include the space used by
dead tuples).  We're only missing the CPU time involved in the tuple
validity check, which is pretty small.

> Took an empty table, with a transaction I inserted a number of records
> and before comitting I ran analyze.

I tried to repeat this:

regression=# begin;
BEGIN
regression=# create table foo (f1 int);
CREATE
regression=# insert into foo [ ... some data ... ]

regression=# analyze foo;
ERROR:  ANALYZE cannot run inside a BEGIN/END block

This seems a tad silly; I can't see any reason why ANALYZE couldn't be
done inside a BEGIN block.  I think this is just a hangover from
ANALYZE's origins as part of VACUUM.  Can anyone see a reason not to
allow it?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problem with restoring a 7.1 dump
Next
From: Lincoln Yeoh
Date:
Subject: Re: Analyze on large changes...