Re: : Tracking Full Table Scans - Mailing list pgsql-performance

From Craig Ringer
Subject Re: : Tracking Full Table Scans
Date
Msg-id 4E827070.4040801@ringerc.id.au
Whole thread Raw
In response to Re: : Tracking Full Table Scans  (Venkat Balaji <venkat.balaji@verse.in>)
Responses Re: : Tracking Full Table Scans  (Venkat Balaji <venkat.balaji@verse.in>)
List pgsql-performance
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

pgsql-performance by date:

Previous
From: Craig Ringer
Date:
Subject: Re: postgres constraint triggers
Next
From: anthony.shipman@symstream.com
Date:
Subject: Re: overzealous sorting?