Return to Question

I have a number of tables with the primary key (month, year, number) and differing cardinalities differ somewhat. For the tuple (month, year) the history doesn't go back very far, this will probably not grow beyond 50 in the very long term. For every (month, year) tuple there are not more than 2 million unique numbers. I want to know which combinations of month and years are available. I do this using this query:

select month, year from table group by month, year

This returns the correct result but does not seem to be very efficient. What is an efficient way to obtain this result (utilizing the unique index)?

The tuning advisor suggests to add an index on month-year for this query but this seems wasteful because a larger index is already available.

I have a number of tables with the primary key (month, year, number) and cardinalities differ somewhat. For the tuple (month, year) the history doesn't go back very far, this will probably not grow beyond 50 in the very long term. For every (month, year) tuple there are not more than 2 million unique numbers. I want to know which combinations of month and years are available. I do this using this query:

select month, year from table group by month, year

This returns the correct result but does not seem to be very efficient. What is an efficient way to obtain this result (utilizing the unique index)?

The tuning advisor suggests to add an index on month-year for this query but this seems wasteful because a larger index is already available.

I have a table with the primary key (month, year, number) and I want to know which combinations of month and years are available. I do this using this query:

select month, year from table group by month, year

I have a number of tables so the cardinalities differ somewhat. For the tuple (month, year) the history doesn't go back very far, this will probably not grow beyond 50 in the very long term. For every month-year combination there are not more then 2 million rows.

This returns the correct result but does not seem to be very efficient. What is an efficient way to obtain this result (utilizing the unique index).

The tuning advisor suggests to add an index on month-year for this query but this seems wasteful because a larger index is already available.

I have a number of tables with the primary key (month, year, number) and differing cardinalities differ somewhat. For the tuple (month, year) the history doesn't go back very far, this will probably not grow beyond 50 in the very long term. For every (month, year) tuple there are not more than 2 million unique numbers. I want to know which combinations of month and years are available. I do this using this query:

select month, year from table group by month, year

This returns the correct result but does not seem to be very efficient. What is an efficient way to obtain this result (utilizing the unique index)?

The tuning advisor suggests to add an index on month-year for this query but this seems wasteful because a larger index is already available.

I have a table with the primary key (month, year, number) and I want to know which combinations of month and years are available. I do this using this query:

select month, year from table group by month, year

This returns the correct result but does not seem to be very efficient. What is an efficient way to obtain this result (utilizing the unique index).

I have a table with the primary key (month, year, number) and I want to know which combinations of month and years are available. I do this using this query:

select month, year from table group by month, year

I have a number of tables so the cardinalities differ somewhat. For the tuple (month, year) the history doesn't go back very far, this will probably not grow beyond 50 in the very long term. For every month-year combination there are not more then 2 million rows.

This returns the correct result but does not seem to be very efficient. What is an efficient way to obtain this result (utilizing the unique index).

The tuning advisor suggests to add an index on month-year for this query but this seems wasteful because a larger index is already available.