Re: [Typo correction] Is it good for performance to put rows that are of different types but are always queried together in the same table partition?

Why can't you have something like this? CREATE TABLE t ( p INT, q1 INT, q2 UUID, c1 INT, c2 TEXT, PRIMARY KEY (p, q1, q2) ) Sounds the simplest solution. Carlos Alonso | Software Engineer | @calonso On 12 January 2016 at 18:27, Bamoqi

Re: [Typo correction] Is it good for performance to put rows that are of different types but are always queried together in the same table partition?

I over-simplified the original example. In the real model I cannot just merge the row types. Suppose create table t1( p int, q1 int, c1 int, primary key( p, q1 ) ) create table t2( p int, q2 uuid, c2 text, primary key(

[Typo correction] Is it good for performance to put rows that are of different types but are always queried together in the same table partition?

[Correction of the original message which contains typos in code.] Is it good for performance to put rows that are of different types but are always queried together in the same table partition? My consideration is that whether doing so will result in better memory/disk cache locality.

Re: [Typo correction] Is it good for performance to put rows that are of different types but are always queried together in the same table partition?

A simple denormalization is probably all that is called for - just merge the two tables into one (their union.) No need for this row type. -- Jack Krupansky On Fri, Jan 8, 2016 at 9:30 AM, Jeff Jirsa wrote: > You’ll see better performance using a slice (which is

Re: [Typo correction] Is it good for performance to put rows that are of different types but are always queried together in the same table partition?

You’ll see better performance using a slice (which is effectively what will happen if you put them into the same table and use query-1table-b), as each node will only need to merge cells/results once. It may not be twice as fast, but it’ll be fast enough to make it worthwhile. On 1/8/16,