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

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: AW: [HACKERS] Really slow query on 6.4.2
Дата
Msg-id Pine.BSF.4.05.9903291437150.6652-100000@thelab.hub.org
обсуждение исходный текст
Ответ на Re: AW: [HACKERS] Really slow query on 6.4.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, 25 Mar 1999, Tom Lane wrote:

> 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?

We're not looking for perfect numbers here, how about something just
stored in cache and periodically written out to disk?  We already have the
shard memory pool to work with...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



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

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: AW: [HACKERS] Really slow query on 6.4.2
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] Really slow query on 6.4.2