Re: help with fragmentation scheme

> We have to fragment a table now because of nearing the page limit size. Yes > we could just change the page size but think at 240million rows, it's > probably a good thing to fragment the table anyway. > > Most queries join that table to other tables based on the token and joined > to another field(stprofil_token). The other field has values that are > spread througout the token range. So if we fragmented on the token field, > it would be good to eliminate the proper fragment, but that would have to > happen many times until it found the right record that contains the > token/stprofil_token value. > > So would the best thing be to try and find a good split of data between > those 2 fields ? Like see if I can fragment with an expression like: > token >;=x and token ;=a and stprofil_token A look at the schema and domains of possible candidate fields would help. I know you mention a "token" but to me a token is something that gets me through the turnstile at Luna Park. What's the type and possible spread of that field? For the fields that might be suitable for fragmenting, give a rough estimate of the typical shape of the data (eg a char(2) might match "[A-Z][A-Z0-9]" or it might be more "[AB][A-Z0-9]") and also give a rough estimate of the number of unique values for that field (eg if it's an American state field, the whole world knows there's about 50 possible values) A nice clean set of SELECT samples will help too As Jarrod mentioned, you might just be better off using round-robin and enabling simple parallelism using the PDQ parameter in the config file. Finally, once a candidate scheme looks promising, test-drive it on a sample database using real SELECTs, and check the query plan that pops out using SET EXPLAIN