Re: Implementing Incremental View Maintenance

Поиск
Список
Период
Сортировка
От Adam Brusselback
Тема Re: Implementing Incremental View Maintenance
Дата
Msg-id CAMjNa7cogDibpuGF=MDdaJGxKmnnz7pcxwp2ZwFFE-WjxUoNsA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Implementing Incremental View Maintenance  (denty <denty@QQdd.eu>)
Ответы Re: Implementing Incremental View Maintenance  (Nguyễn Trần Quốc Vinh <ntquocvinh@gmail.com>)
Re: Implementing Incremental View Maintenance  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Re: Implementing Incremental View Maintenance  (Yugo NAGATA <nagata@sraoss.co.jp>)
Список pgsql-hackers
Hi all, just wanted to say  I am very happy to see progress made on this, my codebase has multiple "materialized tables" which are maintained with statement triggers (transition tables) and custom functions. They are ugly and a pain to maintain, but they work because I have no other solution...for now at least.

I am concerned that the eager approach only addresses a subset of the MV use
case space, though. For example, if we presume that an MV is present because
the underlying direct query would be non-performant, then we have to at
least question whether applying the delta-update would also be detrimental
to some use cases.

I will say that in my case, as long as my reads of the materialized view are always consistent with the underlying data, that's what's important.  I don't mind if it's eager, or lazy (as long as lazy still means it will refresh prior to reading).

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nikolay Shaplov
Дата:
Сообщение: Re: [PATCH] check for ctags utility in make_ctags
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Is MinMaxExpr really leakproof?