pub struct SqlClient /* private fields */ Implementations
Create a new SqlClient wrapping a Kinetica instance
Create a SqlClient with custom defaults
pub async fn execute_paged( &self, sql: &str, offset: i64, limit: i64, ) -> SqlOpResult<SqlResult>
Execute a raw SQL string with custom limit and offset
Execute SQL with full control over options
pub async fn fetch_next_page( &self, paging_table: &str, offset: i64, limit: i64, ) -> SqlOpResult<SqlResult>
Fetch the next page of results using a paging table
When a query returns has_more_records = true, Kinetica creates a temporary paging table containing the full result set. Use this method to fetch subsequent pages from that paging table.
paging_table- The paging table name fromSqlResult::paging_table()offset- The offset within the paging table to start fetching fromlimit- The maximum number of records to fetch
pub async fn execute_all( &self, sql: &str, page_size: i64, ) -> SqlOpResult<SqlResult>
Execute a query and iterate through all pages automatically
This method handles pagination transparently, fetching all pages from the paging table and returning an iterator over all results.
Warning: This loads all results into memory. For very large result sets, consider using execute_paged and fetch_next_page to process results in batches.
sql- The SQL query to executepage_size- The number of records to fetch per page
pub async fn execute_paginated<F>( &self, sql: &str, page_size: i64, callback: F, ) ->SqlOpResult<PaginationStats>
Execute a query and process results page by page with a callback
This is the most memory-efficient way to process large result sets, as it only loads one page at a time.
sql- The SQL query to executepage_size- The number of records to fetch per pagecallback- A function called for each page of results