--- title: "POST /v1/{+session}:partitionQuery" method: POST path: "/v1/{+session}:partitionQuery" tags: ["projects"] --- # POST /v1/{+session}:partitionQuery `POST /v1/{+session}:partitionQuery` Creates a set of partition tokens that can be used to execute a query operation in parallel. Each of the returned partition tokens can be used by ExecuteStreamingSql to specify a subset of the query result to read. The same session and read-only transaction must be used by the `PartitionQueryRequest` used to create the partition tokens and the `ExecuteSqlRequests` that use the partition tokens. Partition tokens become invalid when the session used to create them is deleted, is idle for too long, begins a new transaction, or becomes too old. When any of these happen, it isn't possible to resume the query, and the whole operation must be restarted from the beginning. ## Path parameters - `session` string, required ## Request body - PartitionQueryRequest — The request for PartitionQuery - `transaction` TransactionSelector — This message is used to select the transaction in which a Read or ExecuteSql call runs. See TransactionOptions for more information about transactions. - `singleUse` TransactionOptions — Options to use for transactions. - `readWrite` ReadWrite — Message type to initiate a read-write transaction. Currently this transaction type has no options. - `readLockMode` 'READ_LOCK_MODE_UNSPECIFIED' | 'PESSIMISTIC' | 'OPTIMISTIC' — The read lock mode for the transaction. - `multiplexedSessionPreviousTransactionId` string, byte — Optional. Clients should pass the transaction ID of the previous transaction attempt that was aborted if this transaction is being executed on a multiplexed session. - `partitionedDml` PartitionedDml — Message type to initiate a Partitioned DML transaction. - `readOnly` ReadOnly — Message type to initiate a read-only transaction. - `strong` boolean — Read at a timestamp where all previously committed transactions are visible. - `minReadTimestamp` string, google-datetime — Executes all reads at a timestamp >= `min_read_timestamp`. This is useful for requesting fresher data than some previous read, or data that is fresh enough to observe the effects of some previously committed transaction whose timestamp is known. Note that this option can only be used in single-use transactions. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `maxStaleness` string, google-duration — Read data at a timestamp >= `NOW - max_staleness` seconds. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading the freshest data available at a nearby replica, while bounding the possible staleness if the local replica has fallen behind. Note that this option can only be used in single-use transactions. - `readTimestamp` string, google-datetime — Executes all reads at the given timestamp. Unlike other modes, reads at a specific timestamp are repeatable; the same read at the same timestamp always returns the same data. If the timestamp is in the future, the read is blocked until the specified timestamp, modulo the read's deadline. Useful for large scale consistent reads such as mapreduces, or for coordinating many reads against a consistent snapshot of the data. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `exactStaleness` string, google-duration — Executes all reads at a timestamp that is `exact_staleness` old. The timestamp is chosen soon after the read is started. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading at nearby replicas without the distributed timestamp negotiation overhead of `max_staleness`. - `returnReadTimestamp` boolean — If true, the Cloud Spanner-selected read timestamp is included in the Transaction message that describes the transaction. - `excludeTxnFromChangeStreams` boolean — When `exclude_txn_from_change_streams` is set to `true`, it prevents read or write transactions from being tracked in change streams. * If the DDL option `allow_txn_exclusion` is set to `true`, then the updates made within this transaction aren't recorded in the change stream. * If you don't set the DDL option `allow_txn_exclusion` or if it's set to `false`, then the updates made within this transaction are recorded in the change stream. When `exclude_txn_from_change_streams` is set to `false` or not set, modifications from this transaction are recorded in all change streams that are tracking columns modified by these transactions. The `exclude_txn_from_change_streams` option can only be specified for read-write or partitioned DML transactions, otherwise the API returns an `INVALID_ARGUMENT` error. - `isolationLevel` 'ISOLATION_LEVEL_UNSPECIFIED' | 'SERIALIZABLE' | 'REPEATABLE_READ' — Isolation level for the transaction. - `id` string, byte — Execute the read or SQL query in a previously-started transaction. - `begin` TransactionOptions — Options to use for transactions. - `readWrite` ReadWrite — Message type to initiate a read-write transaction. Currently this transaction type has no options. - `readLockMode` 'READ_LOCK_MODE_UNSPECIFIED' | 'PESSIMISTIC' | 'OPTIMISTIC' — The read lock mode for the transaction. - `multiplexedSessionPreviousTransactionId` string, byte — Optional. Clients should pass the transaction ID of the previous transaction attempt that was aborted if this transaction is being executed on a multiplexed session. - `partitionedDml` PartitionedDml — Message type to initiate a Partitioned DML transaction. - `readOnly` ReadOnly — Message type to initiate a read-only transaction. - `strong` boolean — Read at a timestamp where all previously committed transactions are visible. - `minReadTimestamp` string, google-datetime — Executes all reads at a timestamp >= `min_read_timestamp`. This is useful for requesting fresher data than some previous read, or data that is fresh enough to observe the effects of some previously committed transaction whose timestamp is known. Note that this option can only be used in single-use transactions. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `maxStaleness` string, google-duration — Read data at a timestamp >= `NOW - max_staleness` seconds. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading the freshest data available at a nearby replica, while bounding the possible staleness if the local replica has fallen behind. Note that this option can only be used in single-use transactions. - `readTimestamp` string, google-datetime — Executes all reads at the given timestamp. Unlike other modes, reads at a specific timestamp are repeatable; the same read at the same timestamp always returns the same data. If the timestamp is in the future, the read is blocked until the specified timestamp, modulo the read's deadline. Useful for large scale consistent reads such as mapreduces, or for coordinating many reads against a consistent snapshot of the data. A timestamp in RFC3339 UTC \"Zulu\" format, accurate to nanoseconds. Example: `"2014-10-02T15:01:23.045123456Z"`. - `exactStaleness` string, google-duration — Executes all reads at a timestamp that is `exact_staleness` old. The timestamp is chosen soon after the read is started. Guarantees that all writes that have committed more than the specified number of seconds ago are visible. Because Cloud Spanner chooses the exact timestamp, this mode works even if the client's local clock is substantially skewed from Cloud Spanner commit timestamps. Useful for reading at nearby replicas without the distributed timestamp negotiation overhead of `max_staleness`. - `returnReadTimestamp` boolean — If true, the Cloud Spanner-selected read timestamp is included in the Transaction message that describes the transaction. - `excludeTxnFromChangeStreams` boolean — When `exclude_txn_from_change_streams` is set to `true`, it prevents read or write transactions from being tracked in change streams. * If the DDL option `allow_txn_exclusion` is set to `true`, then the updates made within this transaction aren't recorded in the change stream. * If you don't set the DDL option `allow_txn_exclusion` or if it's set to `false`, then the updates made within this transaction are recorded in the change stream. When `exclude_txn_from_change_streams` is set to `false` or not set, modifications from this transaction are recorded in all change streams that are tracking columns modified by these transactions. The `exclude_txn_from_change_streams` option can only be specified for read-write or partitioned DML transactions, otherwise the API returns an `INVALID_ARGUMENT` error. - `isolationLevel` 'ISOLATION_LEVEL_UNSPECIFIED' | 'SERIALIZABLE' | 'REPEATABLE_READ' — Isolation level for the transaction. - `sql` string — Required. The query request to generate partitions for. The request fails if the query isn't root partitionable. For a query to be root partitionable, it needs to satisfy a few conditions. For example, if the query execution plan contains a distributed union operator, then it must be the first operator in the plan. For more information about other conditions, see [Read data in parallel](https://cloud.google.com/spanner/docs/reads#read_data_in_parallel). The query request must not contain DML commands, such as `INSERT`, `UPDATE`, or `DELETE`. Use `ExecuteStreamingSql` with a `PartitionedDml` transaction for large, partition-friendly DML operations. - `params` object — Optional. Parameter names and values that bind to placeholders in the SQL string. A parameter placeholder consists of the `@` character followed by the parameter name (for example, `@firstName`). Parameter names can contain letters, numbers, and underscores. Parameters can appear anywhere that a literal value is expected. The same parameter name can be used more than once, for example: `"WHERE id > @msg_id AND id < @msg_id + 100"` It's an error to execute a SQL statement with unbound parameters. - `paramTypes` object — Optional. It isn't always possible for Cloud Spanner to infer the right SQL type from a JSON value. For example, values of type `BYTES` and values of type `STRING` both appear in params as JSON strings. In these cases, `param_types` can be used to specify the exact SQL type for some or all of the SQL query parameters. See the definition of Type for more information about SQL types. - `partitionOptions` PartitionOptions — Options for a `PartitionQueryRequest` and `PartitionReadRequest`. - `partitionSizeBytes` string, int64 — **Note:** This hint is currently ignored by `PartitionQuery` and `PartitionRead` requests. The desired data size for each partition generated. The default for this option is currently 1 GiB. This is only a hint. The actual size of each partition can be smaller or larger than this size request. - `maxPartitions` string, int64 — **Note:** This hint is currently ignored by `PartitionQuery` and `PartitionRead` requests. The desired maximum number of partitions to return. For example, this might be set to the number of workers available. The default for this option is currently 10,000. The maximum value is currently 200,000. This is only a hint. The actual number of partitions returned can be smaller or larger than this maximum count request. ## Response `200` Successful response --- [API](https://skmtc.net/google/apis/spanner.md) · [All operations](https://skmtc.net/google/apis/spanner/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/google/spanner/versions/4b66067d2622/schema)