[ https://issues.jboss.org/browse/TEIID-2981?page=com.atlassian.jira.plugin... ] John Muller commented on TEIID-2981: ------------------------------------ [~rareddy] Yes, I figured on both your points, but I don't see a way around extending the OData spec that still provides a result set cache over OData. [~shawkins] I figured there must be caching for skipToken / skip based pagination, thanks for confirming. Our use case is a lengthy SQLServer stored procedure call that comes back with a medium-sized result set (1k to 2k rows). We simply wrapped the physical SPROC in a virtual procedure and then wrapped that in a virtual table. We don't even bother paginating and simply set the batch size to 2048. The issue we're encountering is the length of time the SqlServer SPROC takes is too long and consuming apps tend to hit it repeatedly with the same query. The SPROC has an IN parameter that is basically a user identifier and the underlying tables are much too big for internal materialization. External materialization is an expensive option, but really we only need to cache the user-filtered end result of the SPROC call. OData based caching would help greatly here, but the more generalized use case is for really small ReST queries that are executed repeatedly. -- This message was sent by Atlassian JIRA (v6.2.3#6260)