From: Craig Ringer <ringerc@ringerc.id.au>
To: Venkat Balaji <venkat.balaji@verse.in>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: PGSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: : Tracking Full Table Scans
Date: Wed, 28 Sep 2011 08:55:12 +0800
Message-ID: <4E827070.4040801@ringerc.id.au> (raw)
In-Reply-To: <CAFrxt0iQ45MToxOWd6fq_AdHNomrcWpeDoT6kRudu+ZxQ-G1Cw@mail.gmail.com>
References: <CAFrxt0gyMK8aPS9T1DDdvhaOJjnpC7D_x3kcYURVtw-GhKhF3w@mail.gmail.com>
<4E81981E02000025000417AA@gw.wicourts.gov>
<CAFrxt0iQ45MToxOWd6fq_AdHNomrcWpeDoT6kRudu+ZxQ-G1Cw@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ringerc@ringerc.id.au, venkat.balaji@verse.in, Kevin.Grittner@wicourts.gov
Subject: Re: : Tracking Full Table Scans
In-Reply-To: <4E827070.4040801@ringerc.id.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox