Re: Analyze on large changes...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Rod Taylor" <rbt(at)zort(dot)ca>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Analyze on large changes...
Date: 2002-05-01 14:53:41
Message-ID: 7190.1020264821@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Rod Taylor" <rbt(at)zort(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-01 18:10:39 Re: Analyze on large changes...
Previous Message Tom Lane 2002-05-01 14:34:47 Re: Problem with restoring a 7.1 dump