You should refresh the view in triggers after insert/update/delete/truncate for each statement on table1
and table2
.
create or replace function refresh_mat_view()
returns trigger language plpgsql
as $$
begin
refresh materialized view mat_view;
return null;
end $$;
create trigger refresh_mat_view
after insert or update or delete or truncate
on table1 for each statement
execute procedure refresh_mat_view();
create trigger refresh_mat_view
after insert or update or delete or truncate
on table2 for each statement
execute procedure refresh_mat_view();
In this way your materialized view is always up to date. This simple solution might be hard to accept with frequent inserts/updates and sporadic selects.
In your case (seldom changes about twice a day) it ideally fits your needs.
To realize deferred refresh of a materialized view you need one of the following features:
- asynchronous trigger
- trigger before select
- rule on select before
Postgres has none of them, so it seems that there is no clear postgres solution.
Taking this into account I would consider a wrapper function for selects on mat_view, e.g.
CREATE OR REPLACE FUNCTION select_from_mat_view(where_clause text)
RETURNS SETOF mat_view AS $body$
BEGIN
-- here is checking whether to refresh the mat_view
-- then return the select:
RETURN QUERY EXECUTE FORMAT ('SELECT * FROM mat_view %s', where_clause);
END;
$body$ LANGUAGE plpgsql;
If it is acceptable in practice depends on particulars I do not know about.