Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 8ED292E2DE4 for ; Fri, 14 Dec 2007 20:04:59 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 49998-06 for ; Fri, 14 Dec 2007 20:04:49 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 95DAB2E2DE0 for ; Fri, 14 Dec 2007 20:04:55 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lBF04op3015477; Fri, 14 Dec 2007 19:04:50 -0500 (EST) To: Jeff Davis cc: pgsql-performance@postgresql.org Subject: Re: explanation for seeks in VACUUM In-reply-to: <1197660594.28804.276.camel@dogma.ljc.laika.com> References: <1197660594.28804.276.camel@dogma.ljc.laika.com> Comments: In-reply-to Jeff Davis message dated "Fri, 14 Dec 2007 11:29:54 -0800" Date: Fri, 14 Dec 2007 19:04:50 -0500 Message-ID: <15476.1197677090@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/232 X-Sequence-Number: 28048 Jeff Davis writes: > Where am I going wrong? Are many of these lseeks no-ops or something? They're not supposed to be, but if you only tracked seeks and not reads or writes, it's hard to be sure what's going on. 8.2's VACUUM should process a btree index (this is a btree index no?) in physical order, so I'd expect lseeks only when a page is already in buffers --- at least on the read side. On the write side things might be a great deal less predictable. You're cleaning out about one tuple in 30, so the odds are that nearly every index page is getting dirtied, and they're going to need to be written sometime. regards, tom lane