Tell us what you are trying to do?
I have a pretty complicated system of nested views designed to serve model information for models related to a series.
I'll do my best to break it down...
There's a spec table for every model type (taxonomy) showing the custom field data for each model (post type - child) related to the series (post type - parent) page in which they sit. This limits the models that show up on each table, while still giving us specs for every model related to the series
example:
SeriesTango (post page)
Model Type A will return a spec table with info for Modelx10 and Modelx12
Model Type B will return a spec table with info for Modelb1, Modelb2, Modelb3, Modelb4
Model Type C will return a spec table with info for Modelw6, Modelw8, Modelw10
...and so on...
For each model in the table there are approximately 100 possible rows. In other words, 100 queries through 100 views nested in a table view. When a view query produces a result, the view outputs a row to the table. The row is a container for the loop which produces one cell containing the spec for each model iteration.
When there are just one or two Model Type for a Series, there are one or two specs tables, and thus approximately 100 or 200 queries running on a Series Post. Not great, but not terrible.
But I do have one Series in particular with Six Model Types, creating six tables, with each table containing a wide range of specs for 1 - 6 models (19 models in total across all six tables). At least 600 queries are firing off on load, which drags the load time way down.
One idea I had on how to get the speed back up...
An important thing to note is that I currently use a Switcher - hidden link - for each Model Type / Table. So if we could defer the query for non-active containers until the associated tab is clicked, that would bring the initial load from 600 queries back down to 100 (for the active tab)... This would work like pagination, but I can't think of how to combine the existing pagination tools with something as elegant as the switcher.
But honestly, I'm open to anything. It'd be nice if there was a way to ignore the views that produce rows in each table based on the model type, but I figure wrapping each view a conditional would add another type of query, and adding model type to the query filter for each view doesn't prevent the view from running it's query on page load.
Is there any documentation that you are following?
I read other posts on the forum about having too many nested views and how taxing they can be, but I didn't see any solutions.
Is there a similar example that we can see?
Not that I know of.
What is the link to your site?
I'd be happy to share that information privately, but I will need the Toolset Supporter's IP address to whitelist.
