Re: AW: [HACKERS] Really slow query on 6.4.2

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AW: [HACKERS] Really slow query on 6.4.2
Дата
Msg-id 15024.922390469@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: AW: [HACKERS] Really slow query on 6.4.2  (The Hermit Hacker <scrappy@hub.org>)
Ответы Re: AW: [HACKERS] Really slow query on 6.4.2  (geek+@cmu.edu)
Re: AW: [HACKERS] Really slow query on 6.4.2  (The Hermit Hacker <scrappy@hub.org>)
Список pgsql-hackers
The Hermit Hacker <scrappy@hub.org> writes:
> I'm not sure what is all contained in the stats, but the easiest one, I
> think, to have done automagically is table sizes...add a tuple, update the
> table of number of rows automatically.  If that numbers gets "off", at
> least it will be more reasonable then not doing anything...no?

The number of tuples is definitely the most important stat; updating it
automatically would make the optimizer work better.  The stuff in
pg_statistics is not nearly as important.

The only objection I can think of to auto-updating reltuples is that
it'd mean additional computation (to access and rewrite the pg_class
entry) and additional disk I/O (to write back pg_class) for every INSERT
and DELETE.  There's also a potential problem of multiple backends all
trying to write pg_class and being delayed or even deadlocked because of
it.  (Perhaps the MVCC code will help here.)

I'm not convinced that accurate stats are worth that cost, but I don't
know how big the cost would be anyway.  Anyone have a feel for it?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Going on vacation
Следующее
От: Clark Evans
Дата:
Сообщение: Re: [HACKERS] PostgreSQL LOGO (was: Developers Globe (FINAL))