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

From Rod Taylor
Subject Analyze on large changes...
Date
Msg-id 213a01c1f11b$7e4310e0$ad02000a@jester
Whole thread Raw
Responses Re: Analyze on large changes...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I've run into an interesting issue.  A very long running transaction
doing data loads is getting quite slow.  I really don't want to break
up the transactions (and for now it's ok), but it makes me wonder what
exactly analyze counts.

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?

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

Analyze obviously saw the table as empty, as the pg_statistic row for
that relation doesn't exist.

Commit, then analyze again and the values were taken into account.


Certainly for large dataloads doing an analyze on the table after a
substantial (non-comitted) change has taken place would be worth while
for all elements involved.  An index scan on the visible records may
be faster, but on the actual tuples in the table a sequential scan
might be best.

Of course, for small transactions no-effect will be seen.  But this
may help with the huge dataloads, especially where triggers or
constraints are in effect.
--
Rod



pgsql-hackers by date:

Previous
From: "Magnus Naeslund(f)"
Date:
Subject: Re: Problem with restoring a 7.1 dump
Next
From: Tom Lane
Date:
Subject: Re: Problem with restoring a 7.1 dump