Note
This documentation is for a prior release of Kinetica. For the latest documentation, click here.
Memory-only tables are not persisted by default like a regular table. You can add, modify, or delete records in a memory-only table.
A memory-only table name must adhere to the standard naming criteria. Each memory-only table exists within a schema and follows the standard name resolution rules for persisted tables.
The following scenarios/endpoints will create a memory-only table (unless persistence is specified):
- Using the /aggregate/groupby, /aggregate/unique, or /aggregate/unpivot endpoints with the result_table option specified
- Projection -- created from /create/projection
- Union (also includes intersect and except operations) -- created from /create/union
- Creating a table using /create/table with the is_result_table option set to true
Considerations
- Ingestion speed is better than persisted tables, as there are no disk writes.
- There's no reliance on lookups between connected join data sets or scanning mask on filtered data sets, resulting in faster queries.
- All memory-only tables created by endpoints copy data from their source data sets, thus their memory footprint can be quite large compared to a join view or a filtered view.
Limitations and Cautions
- Primary Key fields contained within memory-only tables cannot be updated.
- Object ID cannot be used to update or delete records.
- Memory-only tables cannot contain store-only or non-charN string column types.
- A memory-only table is not persisted, by default, and will not survive a database restart, though each endpoint that creates a memory-only table has an option to persist the table instead.
- Memory-only tables can be evicted to disk cache if RAM is limited, thus incurring disk writes
- Individual memory-only table types have additional limitations and properties that may differ from the preceding limitations. More information can be found in Aggregation, Except, Intersect, Projections, and Union.
