Message-ID: <4E827070.4040801@ringerc.id.au>
Date: Wed, 28 Sep 2011 08:55:12 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
MIME-Version: 1.0
To: Venkat Balaji <venkat.balaji@verse.in>
CC: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	PGSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: : Tracking Full Table Scans
References: 
 <CAFrxt0gyMK8aPS9T1DDdvhaOJjnpC7D_x3kcYURVtw-GhKhF3w@mail.gmail.com>
	<4E81981E02000025000417AA@gw.wicourts.gov>
	<CAFrxt0iQ45MToxOWd6fq_AdHNomrcWpeDoT6kRudu+ZxQ-G1Cw@mail.gmail.com>
In-Reply-To: 
 <CAFrxt0iQ45MToxOWd6fq_AdHNomrcWpeDoT6kRudu+ZxQ-G1Cw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09/28/2011 12:26 AM, Venkat Balaji wrote:
> Thanks a lot Kevin !!
>
> Yes. I intended to track full table scans first to ensure that only
> small tables or tables with very less pages are (as you said) getting
> scanned full.

It can also be best to do a full table scan of a big table for some 
queries. If the query needs to touch all the data in a table - for 
example, for an aggregate - then the query will often complete fastest 
and with less disk use by using a sequential scan.

I guess what you'd really want to know is to find out about queries that 
do seqscans to match relatively small fractions of the total tuples 
scanned, ie low-selectivity seqscans. I'm not sure whether or not it's 
possible to gather this data with PostgreSQL's current level of stats 
detail.

--
Craig Ringer