Filtered Views

A filtered view is a queryable filter of a table, collection, or another view. A view can also be referred to as a result set. A filtered view can be created by filtering an existing table or view using the /filter endpoint.

Filtered views can be updated to insert the missing data points for a series from the underlying table using /update/records/byseries.

As they are result sets, and given the need to minimize memory usage, filtered views are given a default time-to-live, after which they will expire and be removed from memory. Each access of the filtered view causes the remaining time-to-live to be reset. Thus, a filtered view accessed more frequently than its time-to-live will effectively remain in memory indefinitely.

Filtered views have the same naming criteria as tables.

Creating a Filtered View

To create a filtered view, the /filter endpoint requires three parameters:

1. the name of the data set to create the filtered view from
2. the name of the filtered view to create
3. an expression used to filter the source data set

Example

In Python, given source table my_table, a filtered view can be created via:

gpudb.filter(
  table_name = "my_table",
  view_name = "my_new_view",
  expression = "x > 0"
)

Limitations and Cautions

• When a record contained in a filtered view is modified by an update of the underlying data set, the record is removed from the filtered view regardless of whether the update impacted the record's qualifications for membership in the filtered view
• A filtered view has no permanence by default because it is not protected and will expire after the default TTL setting
• When a data set is cleared (dropped) all the filtered views created from the data set are also automatically cleared
• Records contained in a filtered view cannot be added, edited, or deleted

Memory Implications

A filtered view has a relatively lower memory footprint compared to a join view or an in-memory table, such as a projection or union. Read more about in-memory tables and their relative memory implications on In-Memory Tables.