Thanks Tom, appreciate the reply.
Sorry if I didn't call it the correct thing. I just know that with trying to encapsulate this aggregate logic in a view, I am unable to use that view in a query that I know is only going to touch a subset of the data without incurring a performance hit from the view doing seq scans on all of the rows in the detail_1 and detail_2 tables, and then throwing out 99% of the results when the filter is applied.
I had initially started creating functions that would take an array of ids as a parameter, and manually push them down in the subqueries. That got really really messy though, and we moved away from doing that to having the aggregates eagerly materialized to a table with triggers.
Are there any other options for making this type of query faster? It could be that I just am totally missing a better way to do this. I do really want to be able to contain that logic within a view of some sort though, as a bunch of other stuff is built on top of that. Having to push that aggregate query into all of those other queries would be hell.
Thanks,
-Adam