Pagination - Memory threshold issue.

@saicharanb As per my observation so far, you have been working on the Forms Designer and Paging Grid Component in particular. I believe you are trying to target the performance improvement and also trying to know how the pagingInfo works:

How it works:
1. When it comes to Paging Grid Component that belongs to Forms Designer, data!pagingInfo is the property that takes care of pagination and documentation at https://forum.appian.com/suite/help/16.2/Forms_Designer_Components.html#executing-the-data-set-expression might help you understand this.
2. When it comes to pagingInfo, the startIndex will be 1 initially. Batch size parameter will be controlled by 'Rows per page' attribute of the Paging Grid Forms Designer Component. And with regards to sort, the configuration in the query(or target) rule should take care of this initially(You may also change this default sort behavior by making use of the approach as mentioned at https://forum.appian.com/suite/help/16.2/Forms_Designer_Components.html#specifying-a-default-sort-column). Now the data!pagingInfo keeps track of all the changes in sort and startIndex which we achieve in SAIL by updating the values of Paging Info variable in the 'saveInto' of gridField.

How to overcome the performance issue:
1. Get all the data in the process. Use the BEST practices(batching the data, looping the process in case of large amounts of data) to retrieve data so that this won't hamper the performance, let's say the entire data is stored in a variable called 'queriedData'. While configuring the Paging Grid on the form, use the todatasubset(pv!queriedData,data!pagingInfo). The only difference we are trying to make here is, instead of trying to pull the entire data in the form, we are pulling the data in the process before we hit the form, that too, in the best possible way which thereby overcomes the performance issues and an improved user experience is the additional benefit.

Why retrive all the data in the process:
I believe one might get a doubt as to why we are ending up in retrieving all the data in the process. This is because, in the SAIL, we do have an ability to store the pagingInfo in a variable, update it in 'saveInto' and provide it to the data sorurce rule every time and store fresh values in the data subset variable which could happen all the time when we use with() and on demand when we use load(). As we don't have this kind of mechanism in the Forms Designer(as far as I remember, there isn't any) we use data!pagingInfo which will take care of all the aspects whose startIndex, batchSize, sortInfo will be derived as I have explained earlier. That's why we query the data beforehand in the process so that we don't end up querying a huge amount of data in the form which causes performance issues and a bad user experience. Please note that this works well only for large amounts of data sets and when the data set is small, querying in the form should be fine.

In case if you have any issues in implementation, I would suggest expanding as much as you can on the objects, that is, the definition of the rule, the configuration in Process Model without which giving suggestions might become difficult.

@saicharanb As per my observation so far, you have been working on the Forms Designer and Paging Grid Component in particular. I believe you are trying to target the performance improvement and also trying to know how the pagingInfo works:

How it works:
1. When it comes to Paging Grid Component that belongs to Forms Designer, data!pagingInfo is the property that takes care of pagination and documentation at https://forum.appian.com/suite/help/16.2/Forms_Designer_Components.html#executing-the-data-set-expression might help you understand this.
2. When it comes to pagingInfo, the startIndex will be 1 initially. Batch size parameter will be controlled by 'Rows per page' attribute of the Paging Grid Forms Designer Component. And with regards to sort, the configuration in the query(or target) rule should take care of this initially(You may also change this default sort behavior by making use of the approach as mentioned at https://forum.appian.com/suite/help/16.2/Forms_Designer_Components.html#specifying-a-default-sort-column). Now the data!pagingInfo keeps track of all the changes in sort and startIndex which we achieve in SAIL by updating the values of Paging Info variable in the 'saveInto' of gridField.

How to overcome the performance issue:
1. Get all the data in the process. Use the BEST practices(batching the data, looping the process in case of large amounts of data) to retrieve data so that this won't hamper the performance, let's say the entire data is stored in a variable called 'queriedData'. While configuring the Paging Grid on the form, use the todatasubset(pv!queriedData,data!pagingInfo). The only difference we are trying to make here is, instead of trying to pull the entire data in the form, we are pulling the data in the process before we hit the form, that too, in the best possible way which thereby overcomes the performance issues and an improved user experience is the additional benefit.

Why retrive all the data in the process:
I believe one might get a doubt as to why we are ending up in retrieving all the data in the process. This is because, in the SAIL, we do have an ability to store the pagingInfo in a variable, update it in 'saveInto' and provide it to the data sorurce rule every time and store fresh values in the data subset variable which could happen all the time when we use with() and on demand when we use load(). As we don't have this kind of mechanism in the Forms Designer(as far as I remember, there isn't any) we use data!pagingInfo which will take care of all the aspects whose startIndex, batchSize, sortInfo will be derived as I have explained earlier. That's why we query the data beforehand in the process so that we don't end up querying a huge amount of data in the form which causes performance issues and a bad user experience. Please note that this works well only for large amounts of data sets and when the data set is small, querying in the form should be fine.

In case if you have any issues in implementation, I would suggest expanding as much as you can on the objects, that is, the definition of the rule, the configuration in Process Model without which giving suggestions might become difficult.