> That's why you really need to be more precise in the data structures
> you are planning on using. This can change the results significantly.
>
> So no, I don't have any specific answers to your questions as you don't
> provide any specific information in what you ask.
Yeah. Let me see if I can f
kimky...@fhda.edu ("Kyong Kim") writes:
> I don't have all the details of the schema and workload. Just an
> interesting idea that was presented to me.
> I think the idea is to split a lengthy secondary key lookup into 2 primary
> key lookups and reduce the cost of clustering secondary key with pr
Simon,
Thanks for the feedback.
I don't have all the details of the schema and workload. Just an
interesting idea that was presented to me.
I think the idea is to split a lengthy secondary key lookup into 2 primary
key lookups and reduce the cost of clustering secondary key with primary
key data by
kimky...@fhda.edu ("Kyong Kim") writes:
> I was wondering about a scale out problem.
> Lets say you have a large table with 3 cols and 500+ million rows.
>
> Would there be much benefit in splitting the columns into different tables
> based on INT type primary keys across the tables?
To answer y
Do the 3 tables have different column structures? Or do they all have the
same table structure? For example, is Table1 storing only data for year
1990 and table 2 storing data for 1991 etc? If so you could use a merge
table. (Or do you need transactions, in which case you will need to use
Inno
I was wondering about a scale out problem.
Lets say you have a large table with 3 cols and 500+ million rows.
Would there be much benefit in splitting the columns into different tables
based on INT type primary keys across the tables? The split tables will be
hosted on a same physical instance but
