Re: reindex/vacuum locking/performance?

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: reindex/vacuum locking/performance?
Дата
Msg-id m3he2ntkix.fsf@wolfe.cbbrowne.com
обсуждение исходный текст
Ответ на Re: reindex/vacuum locking/performance?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
After a long battle with technology,matt@ymogen.net ("Matt Clark"), an earthling, wrote:
>> The point is that a big seqscan (either VACUUM or a plain table scan)
>> hits a lot of pages, and thereby tends to fill your cache with pages
>> that aren't actually likely to get hit again soon, perhaps pushing out
>> pages that will be needed again soon.  This happens at both the
>> shared-buffer and kernel-disk-cache levels of caching.
>
> OK, I had thought (wrongly it seems, as usual, but this is how we learn!)
> that a plain VACUUM did not incur a read of all pages.  I still don't
> understand *why* it does, but I'll take your word for it.

How does it know what to do on any given page if it does not read it
in?  It has to evaluate whether tuples can be thrown away or not, and
that requires looking at the tuples.  It may only be looking at a
small portion of the page, but that still requires reading each page.

No free lunch, unfortunately...
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www3.sympatico.ca/cbbrowne/sgml.html
"End users  are just test loads  for verifying that  the system works,
kind of like resistors in an electrical circuit."
-- Kaz Kylheku in c.o.l.d.s

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

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: count(*) slow on large tables
Следующее
От: Neil Conway
Дата:
Сообщение: Re: reindex/vacuum locking/performance?