Re: reindex/vacuum locking/performance? - Mailing list pgsql-performance

From Christopher Browne
Subject Re: reindex/vacuum locking/performance?
Date
Msg-id m3he2ntkix.fsf@wolfe.cbbrowne.com
Whole thread Raw
In response to Re: reindex/vacuum locking/performance?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Rod Taylor
Date:
Subject: Re: count(*) slow on large tables
Next
From: Neil Conway
Date:
Subject: Re: reindex/vacuum locking/performance?