impact of preparing a statement with no parameters

[Adrian Cole]

Hi, team.

Hopefully this is a quick one.

Is there any reason to prefer or avoid preparing a constant statement?

ex


preparedStatement =
session.prepare(QueryBuilder.select("service").distinct().from(TABLE_SERVICE_SPANS));

later

preparedStatement.bind()


vs just executing the CQL directly as a statement literal or otherwise?

[Alexandre Dutra]

Hi Adrian,

By preparing a statement you usually get 2 sorts of improvements:

1. The CQL query does not have to be parsed server-side again and again.
2. Token-aware routing becomes available for free.

For #1, the performance boost is usually negligible, but it is still there. It may make a visible difference if the query is executed very often.

For #2, I should note that token-aware routing is only possible if the query allows it (that is, it should select a single partition key). It's not the case of the query you gave as an example though. For a query like "SELECT * FROM my_table WHERE my_key = ?" instead, preparation would activate token-aware routing transparently for you; the same query executed as a simple statement would not have that property automatically enabled – you would be responsible for providing the so-called "routing key".

All in all, even if you don't immediately perceive any performance boost, the general recommendation is to prepare any query that is going to be executed more than once.

Hope that helps.

Alex

--
You received this message because you are subscribed to the Google Groups "DataStax Java Driver for Apache Cassandra User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-driver-us...@lists.datastax.com.
To view this discussion on the web visit https://groups.google.com/a/lists.datastax.com/d/msgid/java-driver-user/CAHzwyDvDFg84z5GoMrpaB-5RHBBw%3Drudf%3D7CwO5oNNiZDOcwAg%40mail.gmail.com.

--

Alexandre Dutra

e. alexand...@datastax.com
w. www.datastax.com

[Adrian Cole]

Thanks, Alex. This helps a lot!

On Monday, August 3, 2020 at 9:11:12 PM UTC+8, Alexandre Dutra wrote:

Hi Adrian,

By preparing a statement you usually get 2 sorts of improvements:

1. The CQL query does not have to be parsed server-side again and again.
2. Token-aware routing becomes available for free.

For #1, the performance boost is usually negligible, but it is still there. It may make a visible difference if the query is executed very often.

For #2, I should note that token-aware routing is only possible if the query allows it (that is, it should select a single partition key). It's not the case of the query you gave as an example though. For a query like "SELECT * FROM my_table WHERE my_key = ?" instead, preparation would activate token-aware routing transparently for you; the same query executed as a simple statement would not have that property automatically enabled – you would be responsible for providing the so-called "routing key".

All in all, even if you don't immediately perceive any performance boost, the general recommendation is to prepare any query that is going to be executed more than once.

Hope that helps.

Alex

On Sun, Aug 2, 2020 at 5:19 AM Adrian Cole <adria...@gmail.com> wrote:

Hi, team.

Hopefully this is a quick one.

Is there any reason to prefer or avoid preparing a constant statement?

ex


preparedStatement =
session.prepare(QueryBuilder.select("service").distinct().from(TABLE_SERVICE_SPANS));

later

preparedStatement.bind()


vs just executing the CQL directly as a statement literal or otherwise?

--
You received this message because you are subscribed to the Google Groups "DataStax Java Driver for Apache Cassandra User Mailing List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to java-dri...@lists.datastax.com.

To view this discussion on the web visit https://groups.google.com/a/lists.datastax.com/d/msgid/java-driver-user/CAHzwyDvDFg84z5GoMrpaB-5RHBBw%3Drudf%3D7CwO5oNNiZDOcwAg%40mail.gmail.com.