RE: Anyone know any WP which explains about FTS vs Index Scan?
Date: Sun, 15 Apr 2018 16:52:45 -0400
Message-ID: <00e301d3d4fb$b51490a0$1f3db1e0$_at_rsiz.com>
Kellyn nailed it in very few words earlier in the thread.
Pardon me for writing a few extended thoughts about how you in fact tune for time:
Regarding indexes, you have to consider the maintenance time on each transaction as well, IF that takes place at a time you care about.
So even when the CBO chooses an index for a particular query as less costly, you have to consider time cost to maintain the indexes.
THAT can be quite different for OLTP versus more quiescent data stores. And if your queries are running on systems that are built and refreshed in windows where the time is not that important as long as completion takes place without violating the window, it is *sometimes* possible to dramatically reduce the queries that happen later by physical sorting or attribute clustering (and/or zonemaps if you’re on a relevant box), and all that may affect how few rows make the index versus the table scan the faster, cheaper choice.
Sorted physical data (however you got there) can move the CBO bar for index versus FTS by improving the cluster factor in favor of indexes. Zonemaps can prune the candidate blocks (or compression units) for a FTS favoring an FTS.
If you happen to know the superset of columns that will satisfy all your popular queries per table in a batch rebuild system (or batch new period partitioned system), then you may discover that scanning the index (and avoiding the table altogether) is the cheapest thing.
Any silly thumb rule beyond “it depends” that ignores the actual workflow, the actual queries, and the actual data is a recipe for getting it wrong a lot of the time.
When thumb rules are used (as with, pardon the swear word, “best practices”) to stifle thinking or preempt proof of concept experimentations, you get what you deserve.
Thinking about the overall process and data you have, formulating hypotheses, and testing those hypotheses also gets you what you deserve. (Science wins.)
And from your insightful questions and answers over the years on this list, I know you can think very clearly about this yourself, LS. Whether there is a definitive statement from Oracle or not on this matter doesn’t matter. Oh. Except you might have to gain freedom to do the proper science over the argument of someone whose clout exceeds their mental capacity. Finally I think I see your real problem. Sorry about that.
Again, Amen to what Kevlar wrote. Time is almost always THE goal.
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Ls Cheng
Sent: Sunday, April 15, 2018 3:22 PM
To: Frits Hoogland
Cc: Oracle Mailinglist
Subject: Re: Anyone know any WP which explains about FTS vs Index Scan?
Hi
Thanks
Virus-free. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> www.avast.com
On Sat, Apr 14, 2018 at 5:19 PM, Frits Hoogland <frits.hoogland_at_gmail.com> wrote:
My question would be: why an index range scan MUST be used? What is the reason for this person to deem it mandatory?
This would also discard unique index access, which is a different access path than an index range scan.
I question the knowledge of the person if he/she can not see the point of a full table scan or any other different access path.
Even if the documentation would state that an index must be used, and does not provide a valid reason for why it shouldn’t be used, I would discard the advise in the documentation. There are lots of examples where the official documentation is incorrect, and even experts might be wrong; for something to be written in a book doesn’t make it the truth.
Frits Hoogland
http://fritshoogland.wordpress.com <http://fritshoogland.wordpress.com/> frits.hoogland_at_gmail.com
Mobile: +31 6 14180860
-- http://www.freelists.org/webpage/oracle-lReceived on Sun Apr 15 2018 - 22:52:45 CEST