-
low index distinct keys
I have a table A with 3 million rows that spans over 2 months. I have created index on created_date column. Timestamp (minutes,seconds) is not stored in created_date column. Query on this table has a where clause looking for created_date range of 10 days(without any timestamp in where clause). As timestamp is not stored in created_date column, index on that column is showing very low distinct_keys and query is doing lot of Logical IO's. Can someone please advise whether storing timestamp will help in any way to reduce huge Logical IO's.
Thanks
-
why should a timestamp reduce the amount of logical IO? As I understand you limit your query based on a range of 10 days so I don't see the benefit of a timestamp.
Also when accessing 1/6 of all rows (10 days/ total of 60 days) it is probably faster to do a fts then accessing via an index.
Instead of using a index you may partition your table at a daily level. This way you would probably get the best response time for your query.
-
Thanks for your prompt reponse. Query is using the index on created_date column and it has low selectivity. So I thought that this would cause heavy logical io's. I cannot modify query to supress index or add hints to force non usage of index on this column. Can you please suggest me if there is any other way.
Thanks
-
stored outlines work for me
"False data can act only as a distraction. Therefore. I shall refuse to perceive you." - Bomb #20
-
-
Originally Posted by slimdave
drop the index?
I'm curious, how would this lower the logical io's?
If it were me I would use range partitioning based on date.
Then purging data would involve dropping partitions.
-
Originally Posted by gandolf989
I'm curious, how would this lower the logical io's?
Because the query will not be able to use this ineficient index and will be forced to use FTS.
Jurij Modic
ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
-
Originally Posted by jmodic
Because the query will not be able to use this ineficient index and will be forced to use FTS.
ka-ching!
-
If all queries against this table use the 10 day where clause, then the index will never be good to use. If you have any queries going against a specific date, then it's probably good for those (1/60th of the table).
Depends on how big the table really is, in number of blocks (not rows).
If you need to keep the index for other sql, try using stored outlines - they work great for adjusting apps/sql that you can't otherwise modify...
"False data can act only as a distraction. Therefore. I shall refuse to perceive you." - Bomb #20
-
Thanks to everyone. I will explore stored outlines option.
Thanks
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|