Multiple async requests. IN() is a performance nightmare unless you're
querying against a single partition key.
On Fri, Jun 12, 2015 at 1:09 PM Sotirios Delimanolis
wrote:
> Similarly, should we send multiple SELECT requests or a single one with a
> SELECT...IN ?
>
>
>
> On Wednesday, June 10
Similarly, should we send multiple SELECT requests or a single one with a
SELECT...IN ?
On Wednesday, June 10, 2015 11:27 AM, Sotirios Delimanolis
wrote:
Will this "eventually they will all go through" behavior apply to the IN? How
is this query written to the commitlog?
Do you me
Will this "eventually they will all go through" behavior apply to the IN? How
is this query written to the commitlog?
Do you mean prepare a query likeDELETE FROM MastersOfTheUniverse WHERE
mastersID = ?;and execute it asynchronously 3000 times or add 3000 of these
DELETE (bound) prepared stateme
Batches don't work like that. It's possible for some to succeed, and
later, the rest will. Atomic is the incorrect word to use, it's more like
"eventually they will all go through".
Do not use IN(), use a whole bunch of prepared statements asynchronously.
On Wed, Jun 10, 2015 at 9:26 AM Sotirio
Hi,
When executing a DELETE statement with an IN clause, where the list contains
partition keys, what is the underlying behaviour with regards to atomicity?
DELETE FROM MastersOfTheUniverse WHERE mastersID IN ('Man-At-Arms', 'Teela');
Is it going to act like an atomic batch where if one fails, all
