Analyze on large changes...

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Analyze on large changes...
Date: 2002-05-01 14:21:30
Message-ID: 213a01c1f11b$7e4310e0$ad02000a@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-01 14:34:47 Re: Problem with restoring a 7.1 dump
Previous Message Andrew Sullivan 2002-05-01 14:19:58 Re: Failed compile on Sun