Skip to content

tree: resolve bounded staleness in EvalAsOfTimestamp#67741

Merged
craig[bot] merged 2 commits intocockroachdb:masterfrom
otan-cockroach:as_of
Jul 20, 2021
Merged

tree: resolve bounded staleness in EvalAsOfTimestamp#67741
craig[bot] merged 2 commits intocockroachdb:masterfrom
otan-cockroach:as_of

Conversation

@otan
Copy link
Copy Markdown
Contributor

@otan otan commented Jul 19, 2021

See individual commits for details.
Resolves #67555

This commit changes EvalAsOfTimestamp to return an AsOfSystemTime
struct, and stores this struct in various structs across the
codebase (e.g. SemaContext).

This is a precursor commit that allows further information to be stored,
e.g. bounded staleness, "fail fast" in bounded staleness.

Release note: None
@otan otan requested review from a team, nihalpednekar and nvb and removed request for a team July 19, 2021 05:51
@cockroach-teamcity
Copy link
Copy Markdown
Member

This change is Reviewable

Copy link
Copy Markdown
Contributor

@nvb nvb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 17 of 17 files at r1, 8 of 8 files at r2.
Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @nihalpednekar and @otan)


pkg/ccl/logictestccl/testdata/logic_test/as_of, line 126 at r2 (raw file):

does not yet work

Bounded staleness queries in explicit transactions are not something I imagine we will support because the semantics around which timestamp to use are strange and not particularly useful. Consider being more direct here and saying that this is unsupported.


pkg/sql/sem/tree/as_of.go, line 84 at r2 (raw file):

	// Timestamp is the HLC timestamp evaluated from the AS OF SYSTEM TIME clause.
	Timestamp hlc.Timestamp
	// BoundedStaleness is true if the AS OF SYSTEM TIME clause allows bounded

Is "allows" the right word here? That makes it sound like this flag can be ignored. But it can't, right? It changes the semantics of the Timestamp field, from the exact timestamp to evaluate the query to a minimum staleness bound used to dynamically determine the timestamp to evaluate the query.


pkg/sql/sem/tree/as_of.go, line 110 at r2 (raw file):

	opts ...EvalAsOfTimestampOption,
) (AsOfSystemTime, error) {
	o := evalAsOfTimestampOptions{}

This options struct is forced to allocate and escape to the heap, right? I'm trying to remember how many heap allocations this options pattern causes. The static allocation of EvalAsOfTimestampOptionAllowBoundedStaleness avoids one, and then the varargs shouldn't cause any (but worth confirming, they may if not inlined), so maybe this is the only one.

Consider replacing type EvalAsOfTimestampOption func(o *evalAsOfTimestampOptions) with type EvalAsOfTimestampOption func(o evalAsOfTimestampOptions) evalAsOfTimestampOptions to avoid the heap allocation.


pkg/sql/sem/tree/as_of.go, line 119 at r2 (raw file):

		if o.allowBoundedStaleness {
			optFuncs = fmt.Sprintf(
				", %s, %s",

nit: comma at the end of string

Copy link
Copy Markdown
Contributor Author

@otan otan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @nihalpednekar and @nvanbenschoten)


pkg/sql/sem/tree/as_of.go, line 119 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

nit: comma at the end of string

oh no, a believer of the oxford comma D:

Done

Copy link
Copy Markdown
Contributor

@nvb nvb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 4 of 4 files at r3.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @nihalpednekar)


pkg/sql/sem/tree/as_of.go, line 84 at r2 (raw file):

Previously, nvanbenschoten (Nathan VanBenschoten) wrote…

Is "allows" the right word here? That makes it sound like this flag can be ignored. But it can't, right? It changes the semantics of the Timestamp field, from the exact timestamp to evaluate the query to a minimum staleness bound used to dynamically determine the timestamp to evaluate the query.

This comment or the one above should probably also discuss the difference in the meaning of Timestamp when BoundedStaleness is set to true versus when it is set to false.

EvalAsOfTimestamp now can process with_max_staleness and
with_min_timestamp. We take in an option to allow bounded staleness
reads so that it is an opt-in to allow this.

Release note: None
@otan
Copy link
Copy Markdown
Contributor Author

otan commented Jul 20, 2021

bors r=nvanbenschoten

@craig
Copy link
Copy Markdown
Contributor

craig bot commented Jul 20, 2021

Build succeeded:

@craig craig bot merged commit 4d59006 into cockroachdb:master Jul 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

sql: implement bounded staleness builtin functions

3 participants