Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for arbitrary pool keys #2729

Merged
merged 3 commits into from
May 19, 2021
Merged

add support for arbitrary pool keys #2729

merged 3 commits into from
May 19, 2021

Conversation

mccanne
Copy link
Collaborator

@mccanne mccanne commented May 17, 2021

The backend previously presumed the pool key was of type time.
This commit generalizes the scanning logic to allow pool keys of any type.

The seek index has been simplified to use a simple, flat
index that is no longer a "micro index". Instead it is a simple,
single-level list of keys that is used at open to get the
scan range for a row object when the scan is smaller than the
whole object. This design presumes the index will be cached
when running multiple queries over a sub-range within a row object.

While updating tests, we noticed the segment size and row_size
fields were virtually the same so we deleted the size field.

As part of this commit, the index package was updated to use
zson format for key parsing instead of the deprecated tzng format,
so we removed zio/tzngio/builder.go.

Closes #2482

@mccanne mccanne requested a review from a team May 17, 2021 22:02
@mccanne mccanne force-pushed the any-key branch 2 times, most recently from 57b6628 to 056153f Compare May 18, 2021 22:13
mccanne added 2 commits May 18, 2021 15:15
Much of the backend presumed the pool key was of type time.
This commit generalizes the scanning logic to allow pool keys
of any type.

The seek index has been simplified to use a simple, flat
index that is no long a "micro index".  Instead it is a simple,
single-level list of keys that is used at open to get the
scan range for a row object when the scan is smaller than the
whole object.  This design presumes the index will be cached
when running multiple queries over a sub-range within a row object.

While updating tests, we noticed the segment size and row_size
fields were virtually the same so we deleted the size field.

As part of this commit, the index package was updated to use
zson format for key parsing instead of the deprecated tzng format,
so we removed zio/tzngio/builder.go.
compiler/kernel/proc.go Show resolved Hide resolved
compiler/semantic/proc.go Outdated Show resolved Hide resolved
expr/extent/span.go Outdated Show resolved Hide resolved
expr/extent/span.go Outdated Show resolved Hide resolved
expr/extent/span.go Outdated Show resolved Hide resolved
lake/segment/writer.go Outdated Show resolved Hide resolved
lake/segment/writer.go Outdated Show resolved Hide resolved
lake/sorted.go Show resolved Hide resolved
zson/zson.go Show resolved Hide resolved
zng/recordval.go Outdated Show resolved Hide resolved
Copy link
Member

@nwt nwt left a comment

Choose a reason for hiding this comment

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

:shipit:

@mccanne mccanne merged commit dcce5c2 into main May 19, 2021
@mccanne mccanne deleted the any-key branch May 19, 2021 18:58
brim-bot pushed a commit to brimdata/brimcap that referenced this pull request May 19, 2021
This is an auto-generated commit with a Zed dependency update. The Zed PR
brimdata/super#2729, authored by @mccanne,
has been merged.

add support for arbitrary pool keys

The backend previously presumed the pool key was of type time.
This commit generalizes the scanning logic to allow pool keys of any type.

The seek index has been simplified to use a simple, flat
index that is no longer a "micro index".  Instead it is a simple,
single-level list of keys that is used at open to get the
scan range for a row object when the scan is smaller than the
whole object.  This design presumes the index will be cached
when running multiple queries over a sub-range within a row object.

While updating tests, we noticed the segment size and row_size
fields were virtually the same so we deleted the size field.

As part of this commit, the index package was updated to use
zson format for key parsing instead of the deprecated tzng format,
so we removed zio/tzngio/builder.go.

Closes brimdata/super#2482
brim-bot pushed a commit to brimdata/brimcap that referenced this pull request May 19, 2021
This is an auto-generated commit with a Zed dependency update. The Zed PR
brimdata/super#2729, authored by @mccanne,
has been merged.

add support for arbitrary pool keys

The backend previously presumed the pool key was of type time.
This commit generalizes the scanning logic to allow pool keys of any type.

The seek index has been simplified to use a simple, flat
index that is no longer a "micro index".  Instead it is a simple,
single-level list of keys that is used at open to get the
scan range for a row object when the scan is smaller than the
whole object.  This design presumes the index will be cached
when running multiple queries over a sub-range within a row object.

While updating tests, we noticed the segment size and row_size
fields were virtually the same so we deleted the size field.

As part of this commit, the index package was updated to use
zson format for key parsing instead of the deprecated tzng format,
so we removed zio/tzngio/builder.go.

Closes brimdata/super#2482
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.

Zed lakes should handle partition keys other than "ts"
2 participants