[
https://issues.apache.org/jira/browse/CASSANDRA-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13637905#comment-13637905
]
Sylvain Lebresne commented on CASSANDRA-4210:
---------------------------------------------
bq. just tells that the parameter is of type 'key', not a set of type 'key'.
Yes, because that's like if you were writing
{noformat}
select * from Town where key in (2)
{noformat}
but with a marker.
Which means that if we do support that, it'll probably have to use the syntax:
{noformat}
select * from Town where key in ?
{noformat}
for compatibility reasons.
But I'd like to note that "multiget" queries are not necessary more efficient.
It's not because the server don't don't anything smart about it, except
parallelizing each individual queries (but that's really all it does). For
that reason, doing the parallelization client side provides the benefit that
you can start processing answers as they come, instead for waiting for the full
result set. So even though you do "waste" a little more network bandwith
between the client and server, I suspect that in a lot of use cases, you may
actually get better throughput by parallelizing server side.
Anyway, that digression aside, I have no problem adding variadic IN (up to the
minor syntax detail above) if only because when IN is used for the clustering
key (versus the partition one), then it does always improve performance.
> Support for variadic parameters list for "in clause" in prepared cql query
> --------------------------------------------------------------------------
>
> Key: CASSANDRA-4210
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4210
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.1.0
> Environment: prepared cql queries
> Reporter: Pierre Chalamet
> Priority: Minor
>
> This query
> {code}
> select * from Town where key in (?)
> {code}
> only allows one parameter for '?'.
> This means querying for 'Paris' and 'London' can't be executed in one step
> with this prepared statement.
> Current workarounds are:
> * either execute the prepared query 2 times with 'Paris' then 'London'
> * or prepare a new query {{select * from Town where key in (?, ?)}} and bind
> the 2 parameters
> Having a support for variadic parameters list with in clause could improve
> performance:
> * single hop to get the data
> * // fetching server side
--
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
