New answers tagged

1

3 problems with that partitioning: BY HASH is useless. SUBPARTITIONing is useless. Hundreds of partitions is inefficient. Stick with only PARTITION BY RANGE(TO_DAYS(rq_date)). The big benefit is in the 'sliding window'. More comments in my partitioning blog. What percentage of rows have t_id <> -1? If more than about 20%, it won't use an index ...


3

Answer is in the article you are referring to: Here the planner has decided to use a two-step plan: the child plan node visits an index to find the locations of rows matching the index condition, and then the upper plan node actually fetches those rows from the table itself. Word Output here means physical read of values. Child plan does not read ...


2

There are a few problems here: First, as jkavalik says in the comments on the OP, the order of columns in an index matters. Basically, in your case for index_rqcd to be used for filtering on rq_date, t_id has to be used before it can "see" and filter on rq_date. Since usually only one range scan on an index can be done for a query and it has to be the ...


1

In general, if 2 queries are identical, they will have the same sql_id, and as a result, the same execution plan (which may change over the time, but it shouldn't depend on which user executes the query). (** It's oversimplified, because starting with 11g Oracle can generate multiple plans based on values of bind variables, presence of histograms ). So ...



Top 50 recent answers are included