Re: SELECT some_column vs SELECT *

If it's sparsely populated you'll get the same benefit from the schema definition. You don't pay for fields you don't use. > On Nov 24, 2015, at 12:17 PM, Jack Krupansky wrote: > > Are all or ost of the 1000+ columns populated for a given row? If they are > sparse

Re: SELECT some_column vs SELECT *

Are all or ost of the 1000+ columns populated for a given row? If they are sparse you can replace them with a single map collection column which would only occupy the entries that are populated. -- Jack Krupansky On Tue, Nov 24, 2015 at 11:04 AM, Jack Krupansky wrote:

SELECT some_column vs SELECT *

Hi all, If I have the following table: CREATE TABLE t ( pk int, ck int, c1 int, c2 int, ... PRIMARY KEY (pk, ck) ) There are lots of non-clustering columns (1000+). From time to time I need to do a query like this: SELECT c1 FROM t WHERE pk = abc AND ck > xyz; How efficient is this

Re: SELECT some_column vs SELECT *

As always, your queries should drive your data model. Unless you really need 1000+ columns for most queries, you should consider separate tables for the subsets of the columns that need to be returned for a given query. The new 3.0 Materialized View feature can be used to easily create subsets of