Re: reindex/vacuum locking/performance?

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: reindex/vacuum locking/performance?
Date: 2003-10-05 21:57:42
Message-ID: m3he2ntkix.fsf@wolfe.cbbrowne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

After a long battle with technology,matt(at)ymogen(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Neil Conway 2003-10-05 23:32:47 Re: reindex/vacuum locking/performance?
Previous Message Rod Taylor 2003-10-05 19:11:50 Re: count(*) slow on large tables