 |
 |
Chunk ids probably fit into 2 bytes with the current baseline 20k chunks, but chunk IDs are not contiguous integers so I’m not 100% sure. It’s obviously not my call, but personally I would like to have the flexibility to try > 65536 chunks, or to encode spatial binning at finer-than-chunk granularity in the secondary index. Is the storage overhead of an extra 2 bytes per row a deal breaker somehow? > On Feb 18, 2016, at 10:50 AM, Jacek Becla <[log in to unmask]> wrote: > > Fabrice, I think we planned for regular 4 byte int for chunkid. > > But check with others from the group, I am way too busy with the > overall dm type things right now... > > > > On 02/18/2016 09:45 AM, Fabrice Jammes wrote: >> Sorry for nitpicking, but it seems that 8 bytes (a SMALLINT for chunkID >> and a BIGINT for objectId) would be enough to store one raw: >> http://dev.mysql.com/doc/refman/5.5/en/integer-types.html >> >> This would lead to an index of: >> 38 * 10^9 objects * (2+8 bytes) = 380 GB >> >> And, with overhead, 1.2TB. >> >> Can I send these number to Fabio please? >> >> Cheers, > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the QSERV-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1