Could you kindly share these results? Specifically timings, data set sizes, and execution plans.sKwa wrote:I did a test - and its a fact and nothing else, I do not write my opinion. Its your point doesn't prove nothing - because its an opinion.
Composite Key vs. Surrogate Key
Moderator: NorbertKrupa
-
- GURU
- Posts: 527
- Joined: Tue Oct 22, 2013 9:36 pm
- Location: Chicago, IL
- Contact:
Re: Composite Key vs. Surrogate Key
Checkout vertica.tips for more Vertica resources.
Re: Composite Key vs. Surrogate Key
Hi!
[DELETED]
[DELETED]
Last edited by id10t on Wed May 06, 2015 4:31 pm, edited 1 time in total.
-
- GURU
- Posts: 527
- Joined: Tue Oct 22, 2013 9:36 pm
- Location: Chicago, IL
- Contact:
Re: Composite Key vs. Surrogate Key
This isn't a competition. We're trying to understand your argument and are asking how you came to that conclusion (by showing us some empirical results).
I would recommend reading section 5.2 of materialization strategies for column-oriented DBMS and materialization strategies in Vertica.
I would recommend reading section 5.2 of materialization strategies for column-oriented DBMS and materialization strategies in Vertica.
Checkout vertica.tips for more Vertica resources.
Re: Composite Key vs. Surrogate Key
I haven’t done a performance analysis of composite keys vs surrogate keys. But I have seen a case where a customer didn’t have a primary key in a table so was using all columns in the join to identify differences between record sets. So there were probably ~20 columns used in the join, using the <=> operator as well. This join was horrifically slow, even as a merge join.
—Sharon
—Sharon
Sharon Cutter
Vertica Consultant, Zazz Technologies LLC
Vertica Consultant, Zazz Technologies LLC