Reference documentation and code samples for the Cloud Bigtable V2 Client class PartialResultSet.
A partial result set from the streaming query API.
Cloud Bigtable clients buffer partial results received in this message until
a resume_token is received.
The pseudocode below describes how to buffer and parse a stream of
PartialResultSet messages.
Having:
queue of row results waiting to be returned queue
extensible buffer of bytes buffer
a place to keep track of the most recent resume_token
for each PartialResultSet p received {
if p.reset {
ensure queue is empty
ensure buffer is empty
}
if p.estimated_batch_size != 0 {
(optional) ensure buffer is sized to at least p.estimated_batch_size
}
if p.proto_rows_batch is set {
append p.proto_rows_batch.bytes to buffer
}
if p.batch_checksum is set and buffer is not empty {
validate the checksum matches the contents of buffer
(see comments on batch_checksum)
parse buffer as ProtoRows message, clearing buffer
add parsed rows to end of queue
}
if p.resume_token is set {
release results in queue
save p.resume_token in resume_token
}
}
Generated from protobuf message google.bigtable.v2.PartialResultSet
CRC32C checksum of concatenated partial_rows data for the current batch. When present, the buffered data from partial_rows forms a complete parseable message of the appropriate type. The client should mark the end of a parseable message and prepare to receive a new one starting from the next PartialResultSet message. Clients must verify the checksum of the serialized batch before yielding it to the caller. This does NOT mean the values can be yielded to the callers since a resume_token is required to safely do so. If resume_token is non-empty and any data has been received since the last one, this field is guaranteed to be non-empty. In other words, clients may assume that a batch will never cross a resume_token boundary.
↳ resume_token
string
An opaque token sent by the server to allow query resumption and signal that the buffered values constructed from received partial_rows can be yielded to the caller. Clients can provide this token in a subsequent request to resume the result stream from the current point. When resume_token is non-empty, the buffered values received from partial_rows since the last non-empty resume_token can be yielded to the callers, provided that the client keeps the value of resume_token and uses it on subsequent retries. A resume_token may be sent without information in partial_rows to checkpoint the progress of a sparse query. Any previous partial_rows data should still be yielded in this case, and the new resume_token should be saved for future retries as normal. A resume_token will only be sent on a boundary where there is either no ongoing result batch, or batch_checksum is also populated. The server will also send a sentinel resume_token when last batch of partial_rows is sent. If the client retries the ExecuteQueryRequest with the sentinel resume_token, the server will emit it again without any data in partial_rows, then return OK.
↳ reset
bool
If true, any data buffered since the last non-empty resume_token must be discarded before the other parts of this message, if any, are handled.
↳ estimated_batch_size
int
Estimated size of the buffer required to hold the next batch of results. This value will be sent with the first partial_rows of a batch. That is, on the first partial_rows received in a stream, on the first message after a batch_checksum message, and any time reset is true. The client can use this estimate to allocate a buffer for the next batch of results. This helps minimize the number of allocations required, though the buffer size may still need to be increased if the estimate is too low.
CRC32C checksum of concatenated partial_rows data for the current batch.
When present, the buffered data from partial_rows forms a complete
parseable message of the appropriate type.
The client should mark the end of a parseable message and prepare to
receive a new one starting from the next PartialResultSet message.
Clients must verify the checksum of the serialized batch before yielding it
to the caller.
This does NOT mean the values can be yielded to the callers since a
resume_token is required to safely do so.
If resume_token is non-empty and any data has been received since the
last one, this field is guaranteed to be non-empty. In other words, clients
may assume that a batch will never cross a resume_token boundary.
Returns
Type
Description
int
hasBatchChecksum
clearBatchChecksum
setBatchChecksum
CRC32C checksum of concatenated partial_rows data for the current batch.
When present, the buffered data from partial_rows forms a complete
parseable message of the appropriate type.
The client should mark the end of a parseable message and prepare to
receive a new one starting from the next PartialResultSet message.
Clients must verify the checksum of the serialized batch before yielding it
to the caller.
This does NOT mean the values can be yielded to the callers since a
resume_token is required to safely do so.
If resume_token is non-empty and any data has been received since the
last one, this field is guaranteed to be non-empty. In other words, clients
may assume that a batch will never cross a resume_token boundary.
Parameter
Name
Description
var
int
Returns
Type
Description
$this
getResumeToken
An opaque token sent by the server to allow query resumption and signal
that the buffered values constructed from received partial_rows can be
yielded to the caller. Clients can provide this token in a subsequent
request to resume the result stream from the current point.
When resume_token is non-empty, the buffered values received from
partial_rows since the last non-empty resume_token can be yielded to
the callers, provided that the client keeps the value of resume_token and
uses it on subsequent retries.
A resume_token may be sent without information in partial_rows to
checkpoint the progress of a sparse query. Any previous partial_rows data
should still be yielded in this case, and the new resume_token should be
saved for future retries as normal.
A resume_token will only be sent on a boundary where there is either no
ongoing result batch, or batch_checksum is also populated.
The server will also send a sentinel resume_token when last batch of
partial_rows is sent. If the client retries the ExecuteQueryRequest with
the sentinel resume_token, the server will emit it again without any
data in partial_rows, then return OK.
Returns
Type
Description
string
setResumeToken
An opaque token sent by the server to allow query resumption and signal
that the buffered values constructed from received partial_rows can be
yielded to the caller. Clients can provide this token in a subsequent
request to resume the result stream from the current point.
When resume_token is non-empty, the buffered values received from
partial_rows since the last non-empty resume_token can be yielded to
the callers, provided that the client keeps the value of resume_token and
uses it on subsequent retries.
A resume_token may be sent without information in partial_rows to
checkpoint the progress of a sparse query. Any previous partial_rows data
should still be yielded in this case, and the new resume_token should be
saved for future retries as normal.
A resume_token will only be sent on a boundary where there is either no
ongoing result batch, or batch_checksum is also populated.
The server will also send a sentinel resume_token when last batch of
partial_rows is sent. If the client retries the ExecuteQueryRequest with
the sentinel resume_token, the server will emit it again without any
data in partial_rows, then return OK.
Parameter
Name
Description
var
string
Returns
Type
Description
$this
getReset
If true, any data buffered since the last non-empty resume_token must
be discarded before the other parts of this message, if any, are handled.
Returns
Type
Description
bool
setReset
If true, any data buffered since the last non-empty resume_token must
be discarded before the other parts of this message, if any, are handled.
Parameter
Name
Description
var
bool
Returns
Type
Description
$this
getEstimatedBatchSize
Estimated size of the buffer required to hold the next batch of results.
This value will be sent with the first partial_rows of a batch. That is,
on the first partial_rows received in a stream, on the first message
after a batch_checksum message, and any time reset is true.
The client can use this estimate to allocate a buffer for the next batch of
results. This helps minimize the number of allocations required, though the
buffer size may still need to be increased if the estimate is too low.
Returns
Type
Description
int
setEstimatedBatchSize
Estimated size of the buffer required to hold the next batch of results.
This value will be sent with the first partial_rows of a batch. That is,
on the first partial_rows received in a stream, on the first message
after a batch_checksum message, and any time reset is true.
The client can use this estimate to allocate a buffer for the next batch of
results. This helps minimize the number of allocations required, though the
buffer size may still need to be increased if the estimate is too low.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Cloud Bigtable V2 Client - Class PartialResultSet (2.17.1)\n\nVersion latestkeyboard_arrow_down\n\n- [2.17.1 (latest)](/php/docs/reference/cloud-bigtable/latest/V2.PartialResultSet)\n- [2.17.0](/php/docs/reference/cloud-bigtable/2.17.0/V2.PartialResultSet)\n- [2.16.0](/php/docs/reference/cloud-bigtable/2.16.0/V2.PartialResultSet)\n- [2.15.0](/php/docs/reference/cloud-bigtable/2.15.0/V2.PartialResultSet)\n- [2.14.0](/php/docs/reference/cloud-bigtable/2.14.0/V2.PartialResultSet)\n- [2.13.0](/php/docs/reference/cloud-bigtable/2.13.0/V2.PartialResultSet)\n- [2.12.0](/php/docs/reference/cloud-bigtable/2.12.0/V2.PartialResultSet)\n- [2.11.1](/php/docs/reference/cloud-bigtable/2.11.1/V2.PartialResultSet)\n- [2.9.1](/php/docs/reference/cloud-bigtable/2.9.1/V2.PartialResultSet)\n- [2.8.0](/php/docs/reference/cloud-bigtable/2.8.0/V2.PartialResultSet)\n- [2.7.0](/php/docs/reference/cloud-bigtable/2.7.0/V2.PartialResultSet)\n- [2.6.3](/php/docs/reference/cloud-bigtable/2.6.3/V2.PartialResultSet)\n- [2.5.0](/php/docs/reference/cloud-bigtable/2.5.0/V2.PartialResultSet)\n- [2.4.0](/php/docs/reference/cloud-bigtable/2.4.0/V2.PartialResultSet)\n- [2.3.0](/php/docs/reference/cloud-bigtable/2.3.0/V2.PartialResultSet)\n- [2.2.1](/php/docs/reference/cloud-bigtable/2.2.1/V2.PartialResultSet)\n- [2.1.0](/php/docs/reference/cloud-bigtable/2.1.0/V2.PartialResultSet)\n- [2.0.1](/php/docs/reference/cloud-bigtable/2.0.1/V2.PartialResultSet)\n- [1.32.1](/php/docs/reference/cloud-bigtable/1.32.1/V2.PartialResultSet)\n- [1.31.1](/php/docs/reference/cloud-bigtable/1.31.1/V2.PartialResultSet)\n- [1.30.0](/php/docs/reference/cloud-bigtable/1.30.0/V2.PartialResultSet)\n- [1.29.2](/php/docs/reference/cloud-bigtable/1.29.2/V2.PartialResultSet)\n- [1.28.3](/php/docs/reference/cloud-bigtable/1.28.3/V2.PartialResultSet)\n- [1.27.0](/php/docs/reference/cloud-bigtable/1.27.0/V2.PartialResultSet)\n- [1.26.2](/php/docs/reference/cloud-bigtable/1.26.2/V2.PartialResultSet)\n- [1.25.0](/php/docs/reference/cloud-bigtable/1.25.0/V2.PartialResultSet)\n- [1.24.1](/php/docs/reference/cloud-bigtable/1.24.1/V2.PartialResultSet)\n- [1.23.0](/php/docs/reference/cloud-bigtable/1.23.0/V2.PartialResultSet)\n- [1.22.2](/php/docs/reference/cloud-bigtable/1.22.2/V2.PartialResultSet)\n- [1.21.1](/php/docs/reference/cloud-bigtable/1.21.1/V2.PartialResultSet)\n- [1.20.3](/php/docs/reference/cloud-bigtable/1.20.3/V2.PartialResultSet) \nReference documentation and code samples for the Cloud Bigtable V2 Client class PartialResultSet.\n\nA partial result set from the streaming query API.\n\nCloud Bigtable clients buffer partial results received in this message until\na `resume_token` is received.\nThe pseudocode below describes how to buffer and parse a stream of\n`PartialResultSet` messages.\nHaving:\n\n- queue of row results waiting to be returned `queue`\n- extensible buffer of bytes `buffer`\n- a place to keep track of the most recent `resume_token` for each PartialResultSet `p` received { if p.reset { ensure `queue` is empty ensure `buffer` is empty } if p.estimated_batch_size != 0 { (optional) ensure `buffer` is sized to at least `p.estimated_batch_size` } if `p.proto_rows_batch` is set { append `p.proto_rows_batch.bytes` to `buffer` } if p.batch_checksum is set and `buffer` is not empty { validate the checksum matches the contents of `buffer` (see comments on `batch_checksum`) parse `buffer` as `ProtoRows` message, clearing `buffer` add parsed rows to end of `queue` } if p.resume_token is set { release results in `queue` save `p.resume_token` in `resume_token` } }\n\nGenerated from protobuf message `google.bigtable.v2.PartialResultSet`\n\nNamespace\n---------\n\nGoogle \\\\ Cloud \\\\ Bigtable \\\\ V2\n\nMethods\n-------\n\n### __construct\n\nConstructor.\n\n### getProtoRowsBatch\n\nPartial rows in serialized ProtoRows format.\n\n### hasProtoRowsBatch\n\n### setProtoRowsBatch\n\nPartial rows in serialized ProtoRows format.\n\n### getBatchChecksum\n\nCRC32C checksum of concatenated `partial_rows` data for the current batch.\n\nWhen present, the buffered data from `partial_rows` forms a complete\nparseable message of the appropriate type.\nThe client should mark the end of a parseable message and prepare to\nreceive a new one starting from the next `PartialResultSet` message.\nClients must verify the checksum of the serialized batch before yielding it\nto the caller.\nThis does NOT mean the values can be yielded to the callers since a\n`resume_token` is required to safely do so.\nIf `resume_token` is non-empty and any data has been received since the\nlast one, this field is guaranteed to be non-empty. In other words, clients\nmay assume that a batch will never cross a `resume_token` boundary.\n\n### hasBatchChecksum\n\n### clearBatchChecksum\n\n### setBatchChecksum\n\nCRC32C checksum of concatenated `partial_rows` data for the current batch.\n\nWhen present, the buffered data from `partial_rows` forms a complete\nparseable message of the appropriate type.\nThe client should mark the end of a parseable message and prepare to\nreceive a new one starting from the next `PartialResultSet` message.\nClients must verify the checksum of the serialized batch before yielding it\nto the caller.\nThis does NOT mean the values can be yielded to the callers since a\n`resume_token` is required to safely do so.\nIf `resume_token` is non-empty and any data has been received since the\nlast one, this field is guaranteed to be non-empty. In other words, clients\nmay assume that a batch will never cross a `resume_token` boundary.\n\n### getResumeToken\n\nAn opaque token sent by the server to allow query resumption and signal\nthat the buffered values constructed from received `partial_rows` can be\nyielded to the caller. Clients can provide this token in a subsequent\nrequest to resume the result stream from the current point.\n\nWhen `resume_token` is non-empty, the buffered values received from\n`partial_rows` since the last non-empty `resume_token` can be yielded to\nthe callers, provided that the client keeps the value of `resume_token` and\nuses it on subsequent retries.\nA `resume_token` may be sent without information in `partial_rows` to\ncheckpoint the progress of a sparse query. Any previous `partial_rows` data\nshould still be yielded in this case, and the new `resume_token` should be\nsaved for future retries as normal.\nA `resume_token` will only be sent on a boundary where there is either no\nongoing result batch, or `batch_checksum` is also populated.\nThe server will also send a sentinel `resume_token` when last batch of\n`partial_rows` is sent. If the client retries the ExecuteQueryRequest with\nthe sentinel `resume_token`, the server will emit it again without any\ndata in `partial_rows`, then return OK.\n\n### setResumeToken\n\nAn opaque token sent by the server to allow query resumption and signal\nthat the buffered values constructed from received `partial_rows` can be\nyielded to the caller. Clients can provide this token in a subsequent\nrequest to resume the result stream from the current point.\n\nWhen `resume_token` is non-empty, the buffered values received from\n`partial_rows` since the last non-empty `resume_token` can be yielded to\nthe callers, provided that the client keeps the value of `resume_token` and\nuses it on subsequent retries.\nA `resume_token` may be sent without information in `partial_rows` to\ncheckpoint the progress of a sparse query. Any previous `partial_rows` data\nshould still be yielded in this case, and the new `resume_token` should be\nsaved for future retries as normal.\nA `resume_token` will only be sent on a boundary where there is either no\nongoing result batch, or `batch_checksum` is also populated.\nThe server will also send a sentinel `resume_token` when last batch of\n`partial_rows` is sent. If the client retries the ExecuteQueryRequest with\nthe sentinel `resume_token`, the server will emit it again without any\ndata in `partial_rows`, then return OK.\n\n### getReset\n\nIf `true`, any data buffered since the last non-empty `resume_token` must\nbe discarded before the other parts of this message, if any, are handled.\n\n### setReset\n\nIf `true`, any data buffered since the last non-empty `resume_token` must\nbe discarded before the other parts of this message, if any, are handled.\n\n### getEstimatedBatchSize\n\nEstimated size of the buffer required to hold the next batch of results.\n\nThis value will be sent with the first `partial_rows` of a batch. That is,\non the first `partial_rows` received in a stream, on the first message\nafter a `batch_checksum` message, and any time `reset` is true.\nThe client can use this estimate to allocate a buffer for the next batch of\nresults. This helps minimize the number of allocations required, though the\nbuffer size may still need to be increased if the estimate is too low.\n\n### setEstimatedBatchSize\n\nEstimated size of the buffer required to hold the next batch of results.\n\nThis value will be sent with the first `partial_rows` of a batch. That is,\non the first `partial_rows` received in a stream, on the first message\nafter a `batch_checksum` message, and any time `reset` is true.\nThe client can use this estimate to allocate a buffer for the next batch of\nresults. This helps minimize the number of allocations required, though the\nbuffer size may still need to be increased if the estimate is too low.\n\n### getPartialRows"]]