Re: SELECT some_column vs SELECT *

2015-11-24 Thread Jon Haddad
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 you can replace them with a

Re: SELECT some_column vs SELECT *

2015-11-24 Thread Jack Krupansky
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: > As always, your queries

Re: SELECT some_column vs SELECT *

2015-11-24 Thread Jack Krupansky
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