Skip to content
Advertisement

SQL View slow when filtered. Is there a clean way to improve performance?

Let me open with:

SHOWPLAN permission denied in database ‘MyDatabase’.

With that out of the way, I’ll layout my situation.

So, The database I work with has a view that executes fairly quickly.

returns 32 rows in 1 second and includes a non-indexed column of values (IDs) I need to filter on.

If I filter on these IDs directly in the view:

Things slow immensely and it takes 21 seconds to return the 20 rows with that ID.

As an experiment I pushed the unfiltered results into a temporary table and executed the filtered query on the the temporary table:

And found that it returns the filtered results far faster (roughly 1 second)

Is there a cleaner syntax or pattern that can be implemented to achieve the same performance?


UPDATE: View Definition and Description
Manually obfuscated, but I was careful so hopefully there aren’t many errors. Still waiting on SHOWPLAN permissions, so Execution Plan is still pending.

The view’s purpose is to provide a count of all the records that belong to a specific component (CMP.COMPONENT_ID = ‘100’) grouped by location.

“Belonging” is determined by the record’s PROC_CODE (mapped through PROC_ID) being within the CMP’s inclusion range (CMP_INCs) and not in the CMP’s exclusion range (CMP_EXCs).

In practice, exclusion ranges are created for individual codes (the bounds are always equal) making it sufficient to check that the code is not equal a bound.

PROC_CODES can (and don’t always) have an alphabetic prefix or suffix, which makes the ISNUMERIC() comparison necessary.

Records store PROC_IDs for their PROC_CODEs, so it’s necessary to convert the CMP’s PROC_CODE ranges into a set of PROC_IDs for identifying which records belong to that component

The performance issue occurs when trying to filter by DEPARTMENT_ID or LOCATION_ID

[CO_RECORDS] is also a view, but if it’s that deep I’m going turf this to someone with less red tape to fight through.

Advertisement

Answer

Based on the swift down votes, the answer to my question is

‘No, there is not a clean syntax based solution for the improved performance, and asking for one is ignorant of the declarative nature of SQL you simple dirty plebeian’.

From the requests for the view’s definition, it’s clear that performance issues in simple queries should be addressed by fixing the structure of the objects being queried (‘MyView’ in this case) rather than syntactical gymnastics.

For interested parties the issue was resolved by adding a Row_Number() column to the final select in the view definition, wrapping it in a CTE, and using the new column in an always true filter while selecting the original columns.

I have no idea if this is the optimal solution. It doesn’t feel good to me, but it appears to be working.

User contributions licensed under: CC BY-SA
9 People found this is helpful
Advertisement