Thread: Regarding Sequential Scans count increase each time we press refresh .
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
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
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
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
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