Analyze on large changes...

Поиск
Список
Период
Сортировка
От Rod Taylor
Тема Analyze on large changes...
Дата
Msg-id 213a01c1f11b$7e4310e0$ad02000a@jester
обсуждение исходный текст
Ответы Re: Analyze on large changes...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Magnus Naeslund(f)"
Дата:
Сообщение: Re: Problem with restoring a 7.1 dump
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Problem with restoring a 7.1 dump