Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[18.01] Optimize public grid database interactions. #5514
For all four grid types (histories, viz, workflows, and pages), this fetches the community rating and any annotations in the initial SQL query. This eliminates at least two extra queries per response element in the grid. See comment in the history controller for why I am fairly confident this is a good idea for annotations but tags are less obvious - these grids still go back to the postgres server multiple times per rendered item to fetch tags.
I'm confident we should either subqueryload, joinedload, or upgrade to sqlalchemy 2.2 and selectinload the tags as well - but I'm not sure which without being able to hack on a usegalaxy.org.
This also brings in less of the user model (only username instead of all of it) to reduce over-the-wire transmission of unneeded data from postgres to Galaxy.
For workflows we were LEFT OUTER JOIN-ing on the steps of the latest workflow - so we were bringing back a lot of extra rows for data that was completely unused. In light of this, it makes perfect sense to me why published workflows were the slowest of these and I suspect they will all be equally performant after this change (modulo the number of rows in the tables and the number of rows rendered).
xref #5473 (this should resolve the performance issues by and large - we should still render more quickly and stick a spinner on the page).