-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create materialized views per board #418
Comments
Since we do a fair bit of post-processing client-side, materialized views may be entirely unnecessary if we can do good quality caching after processing. |
I want to work on this and #419. |
This one is speculative. It may not deliver any performance improvements over client-side caching. Do #419, but only if you can do it within one day. It's not worth spending more time on. |
I'm working on #419. Should be done by today. |
I predict #419 will take a week to implement properly. Let's move discussion there. |
Hasjob's index page currently retrieves all all job posts given the matching criteria, (a) limited by board and (b) by the last 30 days, unless the archive flag is used. We could make this faster using materialised views:
Create a distinct materialized view per board. Whenever a board is created or deleted, the corresponding view is created or deleted. The view has the same query that
getposts
has, limited to 30 days.When a post is edited (limited to the columns that are necessary for index views), all corresponding materialized views (based on the boards the post is linked to) are refreshed concurrently.
The
getposts
function uses the view unless the archive is needed, in which case it queries the main table.The text was updated successfully, but these errors were encountered: