August 23, 2012 at 2:35 am
My view in the world is that partitioning should be transparent to the user and to the 'programmer'.
So a field [Partitioning_Key] should not appear in the code, but still work efficiently. So the same code can be used for situations where there is a [Partitioning_Key] and were there isn't.
So I would like to define this as:
[Partitioning_Key] AS ([Clientnumber]%(31)) PERSISTED,
My questions:
1. Is my thinking correct?
(Or should the programmer code with the partitioning in mind?)
2. Is the SQL-server capable of using the partioning effective, if the code does not use the [Partitioning_Key] in the where or in the ON clauses?
For master and detail tables the partitioning will be the same. So all the data belonging to a client has the same Clientnumber and the same [Partitioning_Key].
Or can performance be improved by adding to the code, for example adding the [Partitioning_Key] to the ON part of a JOIN clause and adding it to the WHERE clause?
(This makes two code streams one for partitioning and one for non partioning, alternatively use the same code and just have a partitioning key field and not using it in the non partioned world).
Thanks for your time and attention.
Ben Brugman
August 23, 2012 at 3:22 am
If your partitioning key is not referenced at all in queries, then, generally speaking, it will give no performance gains as it will have to scan each partition to find the rows to satisfy the query. *
The point of partitioning is normally to divide your tables using a natural key, like a transaction date, or a month end date etc. in order to immediately narrow down the portion of the dataset that needs to be accessed.
If your clientnumber is a sequential number, you may be able to get gains by defining your partition as ranges of client numbers, but this isn't a simple subject and you shouldn't just jump into partitioning tables without knowing in detail how partitioning works in SQL Server, that you actually require them and what it means for queries.
What sort of data volumes are you dealing with in these tables? Is there always going to be a seek to a specific client number that's already highly selective?
*There are some use cases for a hashing partition like this, but it's not for typical OLTP workloads
August 23, 2012 at 4:36 am
Just a note, partitioning is not about performance improvements most of the time. It's about maintenance, data loads, archiving and things like that.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 27, 2012 at 8:04 am
HowardW (8/23/2012)
:The point of partitioning is normally to divide your tables using a natural key, like a transaction date, or a month end date etc. in order to immediately narrow down the portion of the dataset that needs to be accessed.
:
What sort of data volumes are you dealing with in these tables? Is there always going to be a seek to a specific client number that's already highly selective?
The clientnumbers are used a lot and highly selective. But partitioning is done by a modulo function of the clientnumbers to get an even spread over the partitions. The detail tables use the same partitioning key, most of the detail tables do not have the clientnumber but the partitioning key is there.
HowardW (8/23/2012)
*There are some use cases for a hashing partition like this, but it's not for typical OLTP workloads
GilaMonster (8/23/2012)
Just a note, partitioning is not about performance improvements most of the time. It's about maintenance, data loads, archiving and things like that.
Both of you thank for the last remarks. Partitioning is not designed for OLTP and partitioning is not designed to be transparrant.
This does clear some of my misunderstandings about partitioning.
Thanks for setting me straight,
ben
August 27, 2012 at 8:23 am
I wouldn't go as far as saying it's not for OLTP, for any form of sliding windows where you periodically need to purge older data from a table, it can be awesome and that 's something OLTP does have.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply