RE: Implementing Incremental View Maintenance

Поиск
Список
Период
Сортировка
От r.takahashi_2@fujitsu.com
Тема RE: Implementing Incremental View Maintenance
Дата
Msg-id OS0PR01MB5682A90859F1B7772460A74082F29@OS0PR01MB5682.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Implementing Incremental View Maintenance  (Yugo NAGATA <nagata@sraoss.co.jp>)
Ответы Re: Implementing Incremental View Maintenance  (Yugo NAGATA <nagata@sraoss.co.jp>)
Список pgsql-hackers
Hi Nagata-san,


Thank you for your reply.

> I'll investigate this more, but we may have to prohibit views on partitioned
> table and partitions.

I think this restriction is strict.
This feature is useful when the base table is large and partitioning is also useful in such case.


I have several additional comments on the patch.


(1)
The following features are added to transition table.
- Prolong lifespan of transition table
- If table has row security policies, set them to the transition table
- Calculate pre-state of the table

Are these features only for IVM?
If there are other useful case, they should be separated from IVM patch and
should be independent patch for transition table.


(2)
DEPENDENCY_IMMV (m) is added to deptype of pg_depend.
What is the difference compared with existing deptype such as DEPENDENCY_INTERNAL (i)?


(3)
Converting from normal materialized view to IVM or from IVM to normal materialized view is not implemented yet.
Is it difficult?

I think create/drop triggers and __ivm_ columns can achieve this feature.


Regards,
Ryohei Takahashi



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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: param 'txn' not used in function maybe_send_schema()
Следующее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: Skipping logical replication transactions on subscriber side