[
https://issues.apache.org/jira/browse/CASSANDRA-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13641906#comment-13641906
]
Jonathan Ellis commented on CASSANDRA-5514:
-------------------------------------------
Syntax could be something like
{code}
SELECT *
FROM mytimeseries
WHERE key = foo
USING TIMESTAMP > X
{code}
Alternatives could include
# Adding this to the WHERE clause. However, this would be incompatible with
any existing columns named "timestamp," and implementation would likely be
messier than just letting the parser pull this out for us. Additionally, we've
already decided to not pretend timestamp is a pseudo-column for insert/update.
# Using the {{WITH}} keyword or a new keyword entirely. This may be somewhere
more natural than {{USING}}, but again, having gone with {{USING}} on
insert/update, it seems like a good idea to be consistent here.
> Allow timestamp hints
> ---------------------
>
> Key: CASSANDRA-5514
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5514
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Fix For: 2.0
>
>
> Slice queries can't optimize based on timestamp except for rare cases
> (CASSANDRA-4116). However, many common queries involve an implicit time
> component, where the application author knows that he is only interested in
> data more recent than X, or older than Y.
> We could use the per-sstable max and min timestamps we track to avoid
> touching cold data if we could pass a hint to Cassandra about the time range
> we care about.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
