assume transactions to be so small to be able
to hold the queue in memory.
Hmm. I hadn’t really thought about that particular corner case. I guess a
‘catch' could be simply be to detect such a concurrent update and demote the
refresh approach by marking the MV stale awaiting a full refresh.
denty.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
advanced delta-refresh
strategies to emerge that are written in high level languages such as
PL/pgSQL or Java (etc.) — that is certainly desirable.
denty.
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
pe = 'main';" —
with fairly obvious semantics.
Welcome comments on the patch or approach.
denty.
(Seems I can't attach via the web interface, so copy/paste patch below.)
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
The idea of allowing a WHERE clause to be appended to REFRESH MATERIALIZED
VIEW seems useful.
It would enable those that know well the pattern of data modification in
their underlying use case to schedule delta-updates (say, from crontab).
And also it would be a useful as a foundation for more am
