# Uses of Class
com.ocient.jdbc.proto.PlanProtocol.SortPartition.Builder

Packages that use PlanProtocol.SortPartition.Builder
Package | Description
--- | ---
com.ocient.jdbc.proto |

## Uses of PlanProtocol.SortPartition.Builder in com.ocient.jdbc.proto

Methods in com.ocient.jdbc.proto that return PlanProtocol.SortPartition.Builder
Modifier and Type | Method | Description
--- | --- | ---

`PlanProtocol.SortPartition.Builder`

PlanProtocol.SortPartition.Builder.`addAllDenormVal​(Iterable<? extends Float> values)`

The values are guaranteed to be in sort key order There may not be a value for all sort keys though For example, there may only be a value for the first sort key, which means we can partition only on that and we don't need to worry about subsequent sort keys All partitions are closed on the lower side and open on the higher side

`PlanProtocol.SortPartition.Builder`

PlanProtocol.SortPartition.Builder.`addDenormVal​(float value)`

The values are guaranteed to be in sort key order There may not be a value for all sort keys though For example, there may only be a value for the first sort key, which means we can partition only on that and we don't need to worry about subsequent sort keys All partitions are closed on the lower side and open on the higher side

`PlanProtocol.SortPartition.Builder` | PlanProtocol.IndexAggOperator.Builder.`addPointBuilder()` | `repeated .xg.db.sqlPlans.SortPartition point = 16;`
`PlanProtocol.SortPartition.Builder` | PlanProtocol.IndexAggOperator.Builder.`addPointBuilder​(int index)` | `repeated .xg.db.sqlPlans.SortPartition point = 16;`
`PlanProtocol.SortPartition.Builder` | PlanProtocol.IndexDistinctOperator.Builder.`addPointBuilder()` | `repeated .xg.db.sqlPlans.SortPartition point = 12;`
`PlanProtocol.SortPartition.Builder` | PlanProtocol.IndexDistinctOperator.Builder.`addPointBuilder​(int index)` | `repeated .xg.db.sqlPlans.SortPartition point = 12;`

`PlanProtocol.SortPartition.Builder`

PlanProtocol.SortOperator.Builder.`addPointBuilder()`

This defines the list of partitioning points for dividing the sort into streams There's no guarantees on the size of this It could be completely empty, which could happen if it look like all the data has the same sort key - implies that we don't know what to do besides one sort stream There is no guarantee that the partitioning points are in order

`PlanProtocol.SortPartition.Builder`

PlanProtocol.SortOperator.Builder.`addPointBuilder​(int index)`

This defines the list of partitioning points for dividing the sort into streams There's no guarantees on the size of this It could be completely empty, which could happen if it look like all the data has the same sort key - implies that we don't know what to do besides one sort stream There is no guarantee that the partitioning points are in order

`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`addRepeatedField​(com.google.protobuf.Descriptors.FieldDescriptor field, Object value)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`clear()` |

`PlanProtocol.SortPartition.Builder`

PlanProtocol.SortPartition.Builder.`clearDenormVal()`

The values are guaranteed to be in sort key order There may not be a value for all sort keys though For example, there may only be a value for the first sort key, which means we can partition only on that and we don't need to worry about subsequent sort keys All partitions are closed on the lower side and open on the higher side

`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`clearField​(com.google.protobuf.Descriptors.FieldDescriptor field)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`clearOneof​(com.google.protobuf.Descriptors.OneofDescriptor oneof)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`clone()` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.IndexAggOperator.Builder.`getPointBuilder​(int index)` | `repeated .xg.db.sqlPlans.SortPartition point = 16;`
`PlanProtocol.SortPartition.Builder` | PlanProtocol.IndexDistinctOperator.Builder.`getPointBuilder​(int index)` | `repeated .xg.db.sqlPlans.SortPartition point = 12;`

`PlanProtocol.SortPartition.Builder`

PlanProtocol.SortOperator.Builder.`getPointBuilder​(int index)`

This defines the list of partitioning points for dividing the sort into streams There's no guarantees on the size of this It could be completely empty, which could happen if it look like all the data has the same sort key - implies that we don't know what to do besides one sort stream There is no guarantee that the partitioning points are in order

`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`mergeFrom​(com.google.protobuf.CodedInputStream input, com.google.protobuf.ExtensionRegistryLite extensionRegistry)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`mergeFrom​(com.google.protobuf.Message other)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`mergeFrom​(PlanProtocol.SortPartition other)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`mergeUnknownFields​(com.google.protobuf.UnknownFieldSet unknownFields)` |
`static PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.`newBuilder()` |
`static PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.`newBuilder​(PlanProtocol.SortPartition prototype)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.`newBuilderForType()` |
`protected PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.`newBuilderForType​(com.google.protobuf.GeneratedMessageV3.BuilderParent parent)` |

`PlanProtocol.SortPartition.Builder`

PlanProtocol.SortPartition.Builder.`setDenormVal​(int index, float value)`

The values are guaranteed to be in sort key order There may not be a value for all sort keys though For example, there may only be a value for the first sort key, which means we can partition only on that and we don't need to worry about subsequent sort keys All partitions are closed on the lower side and open on the higher side

`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`setField​(com.google.protobuf.Descriptors.FieldDescriptor field, Object value)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`setRepeatedField​(com.google.protobuf.Descriptors.FieldDescriptor field, int index, Object value)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.Builder.`setUnknownFields​(com.google.protobuf.UnknownFieldSet unknownFields)` |
`PlanProtocol.SortPartition.Builder` | PlanProtocol.SortPartition.`toBuilder()` |

Methods in com.ocient.jdbc.proto that return types with arguments of type PlanProtocol.SortPartition.Builder
Modifier and Type | Method | Description
--- | --- | ---
`List<PlanProtocol.SortPartition.Builder>` | PlanProtocol.IndexAggOperator.Builder.`getPointBuilderList()` | `repeated .xg.db.sqlPlans.SortPartition point = 16;`
`List<PlanProtocol.SortPartition.Builder>` | PlanProtocol.IndexDistinctOperator.Builder.`getPointBuilderList()` | `repeated .xg.db.sqlPlans.SortPartition point = 12;`

`List<PlanProtocol.SortPartition.Builder>`

PlanProtocol.SortOperator.Builder.`getPointBuilderList()`

This defines the list of partitioning points for dividing the sort into streams There's no guarantees on the size of this It could be completely empty, which could happen if it look like all the data has the same sort key - implies that we don't know what to do besides one sort stream There is no guarantee that the partitioning points are in order

Methods in com.ocient.jdbc.proto with parameters of type PlanProtocol.SortPartition.Builder
Modifier and Type | Method | Description
--- | --- | ---
`PlanProtocol.IndexAggOperator.Builder` | PlanProtocol.IndexAggOperator.Builder.`addPoint​(int index, PlanProtocol.SortPartition.Builder builderForValue)` | `repeated .xg.db.sqlPlans.SortPartition point = 16;`
`PlanProtocol.IndexAggOperator.Builder` | PlanProtocol.IndexAggOperator.Builder.`addPoint​(PlanProtocol.SortPartition.Builder builderForValue)` | `repeated .xg.db.sqlPlans.SortPartition point = 16;`
`PlanProtocol.IndexDistinctOperator.Builder` | PlanProtocol.IndexDistinctOperator.Builder.`addPoint​(int index, PlanProtocol.SortPartition.Builder builderForValue)` | `repeated .xg.db.sqlPlans.SortPartition point = 12;`
`PlanProtocol.IndexDistinctOperator.Builder` | PlanProtocol.IndexDistinctOperator.Builder.`addPoint​(PlanProtocol.SortPartition.Builder builderForValue)` | `repeated .xg.db.sqlPlans.SortPartition point = 12;`

`PlanProtocol.SortOperator.Builder`

PlanProtocol.SortOperator.Builder.`addPoint​(int index, PlanProtocol.SortPartition.Builder builderForValue)`

This defines the list of partitioning points for dividing the sort into streams There's no guarantees on the size of this It could be completely empty, which could happen if it look like all the data has the same sort key - implies that we don't know what to do besides one sort stream There is no guarantee that the partitioning points are in order

`PlanProtocol.SortOperator.Builder`

PlanProtocol.SortOperator.Builder.`addPoint​(PlanProtocol.SortPartition.Builder builderForValue)`

This defines the list of partitioning points for dividing the sort into streams There's no guarantees on the size of this It could be completely empty, which could happen if it look like all the data has the same sort key - implies that we don't know what to do besides one sort stream There is no guarantee that the partitioning points are in order

`PlanProtocol.IndexAggOperator.Builder` | PlanProtocol.IndexAggOperator.Builder.`setPoint​(int index, PlanProtocol.SortPartition.Builder builderForValue)` | `repeated .xg.db.sqlPlans.SortPartition point = 16;`
`PlanProtocol.IndexDistinctOperator.Builder` | PlanProtocol.IndexDistinctOperator.Builder.`setPoint​(int index, PlanProtocol.SortPartition.Builder builderForValue)` | `repeated .xg.db.sqlPlans.SortPartition point = 12;`

`PlanProtocol.SortOperator.Builder`

PlanProtocol.SortOperator.Builder.`setPoint​(int index, PlanProtocol.SortPartition.Builder builderForValue)`

This defines the list of partitioning points for dividing the sort into streams There's no guarantees on the size of this It could be completely empty, which could happen if it look like all the data has the same sort key - implies that we don't know what to do besides one sort stream There is no guarantee that the partitioning points are in order