X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id EA7209DCAE5 for ; Thu, 5 Jan 2006 23:06:53 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 76935-08 for ; Thu, 5 Jan 2006 23:06:58 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id A23949DCAEF for ; Thu, 5 Jan 2006 23:06:51 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 3085033A69; Fri, 6 Jan 2006 04:06:56 +0100 (MET) From: "Qingqing Zhou" X-Newsgroups: pgsql.performance Subject: Re: Help in avoiding a query 'Warm-Up' period/shared buffer cache Date: Thu, 5 Jan 2006 22:08:05 -0500 Organization: Hub.Org Networking Services Lines: 22 Message-ID: References: <200601041449.43557.mliberman@mixedsignals.com> <200601051815.36181.mliberman@mixedsignals.com> X-Complaints-To: usenet@news.hub.org X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.153 required=5 tests=[AWL=0.153] X-Spam-Score: 0.153 X-Spam-Level: X-Archive-Number: 200601/29 X-Sequence-Number: 16507 "Mark Liberman" wrote > > Now, my follow-up question / assumption. I am assuming that the IO time > is > so long on that index because it has to read the entire index (for that > file_id) into memory > > any confirmation / corrections to my assumptions are greatly appreciated. > E.g. is > the compound index the way to go, or the solo index on file_id? > Only part of the index file is read. It is a btree index. Keep the index smaller but sufficient to guide your search is always good because even by the guidiance of the index, a heap visit to get the real data is not avoidable. Regards, Qingqing