Thread: Regarding Sequential Scans count increase each time we press refresh .

Regarding Sequential Scans count increase each time we press refresh .

From
keshav upadhyaya
Date:
Hi ,

I have one table  my_test table . with on index created on one column .


I have turned off the sequential scans .

Now when ever i do refresh on this table or press F5 , It increase the sequential scans count and
Sequential tuple read count .

Pls help me to understand what exactly is happening ?  Is it scanning the Table sequentially once i press refresh  ?

Thanks,
keshav

Re: Regarding Sequential Scans count increase each time we press refresh .

From
Josh Berkus
Date:
Keshav,

> I have one table  my_test table . with on index created on one column .
>
>
> I have turned off the sequential scans .
>
> Now when ever i do refresh on this table or press F5 , It increase the
> sequential scans count and
> Sequential tuple read count .

What's a "refresh"?

You can't "turn off" sequential scans.  You can only make the planner
less likely to choose them.  But if there's no way to get the data you
need other than a seqscan, it's still going to do one.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Re: Regarding Sequential Scans count increase each time we press refresh .

From
Robert Haas
Date:
On Thu, Sep 24, 2009 at 8:25 PM, Josh Berkus <josh@agliodbs.com> wrote:
> You can't "turn off" sequential scans.  You can only make the planner
> less likely to choose them.  But if there's no way to get the data you
> need other than a seqscan, it's still going to do one.

And that's not a bad thing.  For a very small table, it's often the
fastest method.

...Robert

Re: Regarding Sequential Scans count increase each time we press refresh .

From
Tom Lane
Date:
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Sep 24, 2009 at 8:25 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> You can't "turn off" sequential scans. �You can only make the planner
>> less likely to choose them. �But if there's no way to get the data you
>> need other than a seqscan, it's still going to do one.

> And that's not a bad thing.  For a very small table, it's often the
> fastest method.

Probably more to the point: if the query involves fetching the whole
table, it's *always* the fastest method.  (Except maybe if you want
the results sorted, and often it's the fastest way even so.)  Indexes
are not a panacea.

            regards, tom lane