+1 (non-binding)
Checked the following:
* Verified the signatures
* Verified the checksums
* Verified the license documentation
* Verified the iceberg spark release binary by downloading the runtime jar
from the 1.7.0 release repo. Ran a basic iceberg workflow (DDL, DML, DQL) usin
nt to get the
file-scan-tasks associated with a plan-task by providing a plan-task as input.
Thanks,
Steve Zhang
On Sep 4, 2024, at 9:53 AM, Chertara, Rahil wrote:
1. An endpoint fetchScanTasks was added in order for a client to get the
file-scan-tasks associated with a plan-task by providing a plan-task as input.
thread before voting, to make sure people are aware of the latest design and
address any additional comments?
Best,
Jack Ye
[1] https://lists.apache.org/thread/qq13468x6gk0vxnsckzc5xd02tjlvpkm
On Mon, Sep 2, 2024 at 9:22 PM Chertara, Rahil
wrote:
Hi all,
I've opened a PR [1] to add RE
Hi all,
I've opened a PR [1] to add REST spec changes for a new protocol around table
scan planning. For context around the design discussions, see the original
google doc proposal [2], the dev list discussion thread [3], and finally the
discussion that has happened on the spec change PR.
Plea
allow it to be
opaque and specific to catalogs implementing the protocol. I've not replied
because I keep coming back to this decision and I'm not sure whether the
advantage is being clear about how it works (being explicit) or allowing
implementations to differ (opaque). I'm ske
To make it possible for the service to be stateless, I'm proposing that rather
than creating shard IDs that are tracked by the service, the information for a
shard can be sent to the client. My assumption here is that most
implementations would create shards by reading the manifest list, fil
Hi all,
My name is Rahil Chertara, and I’m a part of the Iceberg team at Amazon EMR and
Athena. I’m reaching out to share a proposal for a new Scan API that will be
utilized by the RESTCatalog. The process for table scan planning is currently
done within client engines such as Apache Spark. By
