Partitioning and Performance of DB Table [closed]

Question

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

Closed 1 year ago.

Improve this question

After partitioning a table the performance of select queries returning large datasets degrades as compared to performance earlier. For small datasets there is no degradation. No change in index is done.What can be reason and is it normal?

An obfuscated/sample query is:

Select * from Table where code >123

Table is partitioned on column code.

@paul white , I am asking the reason why this query is slow after partitioning on column of filtering condition.

Due to reason I cannot share the query but query and indexes remain same before and after partitioning on a code column. What can be possible reasons?

Moreover, after partitioning the slowed query use more than one partition but it is not somehow avoidable.

Partitioning is Hash based wrapper over table (not b-tree) independent of the internal structure of table. Please correct me if I am wrong with ref.

Answer 1

Partitioning's primary purpose is not performance, but management of large amounts of data. By partitioning data, you are actually spreading it across multiple data structures (such as B-trees), and likely increasing the amount of operations required to retrieve that data for your queries.

The scenario where partitioning can help is called partition elimination, where your query is designed in such a way that SQL Server can guarantee it only needs to access some of those many B-trees (or other storage structures) you built. Some more information on that here.

Just like NOLOCK, partitioning is not a magic "go-faster" setting. You need to understand what it's doing and why you're using it.