You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 8, 2018. It is now read-only.
Over on #1549 we've discussed view materialization. I propose that we try it out to gain experience with the technique. I think team memberships would be a good place to explore this pattern because the team memberships page is known to be super slow (#1417) and it's fairly isolated from the rest of the schema.
The text was updated successfully, but these errors were encountered:
`memberships` was a bad name for this table because it's ambiguous with
community memberships. Renaming to `takes` fits the usage we've arrived
at and is parallel to `tips`. Tips and takes! Membership is then an
emergent property of data recorded in the takes table.
I've submitted a PR to rename memberships to takes as a precursor to working on this issue. However, after looking at #1417 I believe that materializing (what is now) the current_takes view is not what is needed to speed up the members listing.
`memberships` was a bad name for this table because it's ambiguous with
community memberships. Renaming to `takes` fits the usage we've arrived
at and is parallel to `tips`. Tips and takes! Membership is then an
emergent property of data recorded in the takes table.
Over on #1549 we've discussed view materialization. I propose that we try it out to gain experience with the technique. I think team memberships would be a good place to explore this pattern because the team memberships page is known to be super slow (#1417) and it's fairly isolated from the rest of the schema.
The text was updated successfully, but these errors were encountered: