Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Transparent partitioning.


Transparent partitioning.

Author
Message
ben.brugman
ben.brugman
SSC-Addicted
SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)

Group: General Forum Members
Points: 469 Visits: 2242
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
HowardW
HowardW
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1211 Visits: 9892
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
GilaMonster
GilaMonster
SSC-Forever
SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)

Group: General Forum Members
Points: 47263 Visits: 44392
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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


ben.brugman
ben.brugman
SSC-Addicted
SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)SSC-Addicted (469 reputation)

Group: General Forum Members
Points: 469 Visits: 2242
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
GilaMonster
GilaMonster
SSC-Forever
SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)SSC-Forever (47K reputation)

Group: General Forum Members
Points: 47263 Visits: 44392
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

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search