[
https://issues.apache.org/jira/browse/CASSANDRA-18201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacek Lewandowski updated CASSANDRA-18201:
------------------------------------------
Resolution: Duplicate
Status: Resolved (was: Triage Needed)
> Store min and max partition key in sstable stats metadata rather than in some
> index component
> ---------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18201
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18201
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
> Reporter: Jacek Lewandowski
> Assignee: Jacek Lewandowski
> Priority: Normal
>
> Currently min and max partition key is stored in the index summary.
> Firstly, that informat better fits stats metadata as there are other similar
> statistics (like min and max clusterings)
> Secondly, opening index summary is costly. Though, index summary and the
> index itself are loaded upon opening an sstable just because we need to read
> min and max partition keys. Min and max partition keys need to be know for an
> sstable so that when some data are queried, we can select the sstable which
> may contain that data - that is, whether the queried partition is included in
> the min/max key range of the sstable.
> With the proposed solution, we could postpone loading index components to the
> time when the data from such sstable is really requested. It will be enough
> to read lightweight stats metadata as it will be sufficient to know
> everything about data ranges included in that sstable. It will also let to
> save memory used by those components until data from those sstables are
> requested.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
