Re: possible vacuum improvement?

Поиск
Список
Период
Сортировка
Искать
От
Rod Taylor
Тема
Re: possible vacuum improvement?
Дата
Msg-id
1031065796.43658.42.camel@jester
Ответ на
Список
Дерево обсуждения
Re: possible vacuum improvement? "Mario Weilguni" <mario.weilguni@icomedias.com>
Re: possible vacuum improvement? Tom Lane <tgl@sss.pgh.pa.us>
Re: possible vacuum improvement? "Matthew T. OConnor" <matthew@zeut.net>
Re: possible vacuum improvement? Mario Weilguni <mweilguni@sime.com>
Re: possible vacuum improvement? "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: possible vacuum improvement? "Matthew T. OConnor" <matthew@zeut.net>
Re: possible vacuum improvement? Richard Tucker <richt@peerdirect.com>
Re: possible vacuum improvement? "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
On Tue, 2002-09-03 at 11:01, Tom Lane wrote:
> "Shridhar Daithankar"  writes:
> > 1)Is this sounds like a workable solution?
> 
> Adding a trigger to every tuple update won't do at all.  Storing the
> counts in a table won't do either, as the updates on that table will
> generate a huge amount of wasted space themselves (not to mention
> enough contention to destroy concurrent performance).
> 
> > 4)Is use of threads sounds portable enough?
> 
> Threads are completely out of the question, at least if you have any
> hope of seeing this code get accepted into the core distro.
> 
> 
> For vacuum's purposes all that we really care to know about is the
> number of obsoleted tuples in each table: committed deletes and updates,
> and aborted inserts and updates all count.  Furthermore, we do not need
> or want a 100% reliable solution; approximate counts would be plenty
> good enough.

It would be nice if it could track successful inserts, and fire off an
analyze run when it changes more than 20% from what stats says.


В списке pgsql-hackers по дате отправления
От: Serguei A. Mokhov
Дата:
Сообщение: Re: Memory management question
От: Tom Lane
Дата:
FAQ