In my experience so far, it has only been a problem if you place the list of things from Y as a repeating group within a repeating group list from X. Then it loads all of Y as well as all of X, which is exponential rather than linear query, hence the large WU cost. May also be answered in the WU webinar today.
That would mean the end of nested RGs…
It seems, from my forum studies, that even with pagination, all the data in a table is searched and charged in WU count form the moment the element is loaded in the page.
And yet one of the examples in the webinar was encouraging us to use these lists instead of searching for related data types. They’re promoting workarounds to avoid being charged $ for their own ineffiencies which is pretty unbelievable.
Pagination shrinks the amount of “things” Bubble will load from the server. So if you are using a fixed RG (amount of rows and columns is fixed) with X cells → Bubble will load only X “things” (plus related “things” for your nested RG). In the same time all fields of a “thing” are returned from DB even if you need only 1 field to display.
There is a couple of ways to reduce the amount of data:
using satellite data types (you can have a satellite data type for using on search pages, for example. And within satellite data type you can have only fields you’ll need to display). But after new pricing model announcements I’m not sure if satellite data types maintenance (CRUD) will not become too expensive in WUs.
using privacy rules (that’s not a solid solution, but it exists).
Josh mentioned that there are investigating in this area (here)