Postgresql 来自渴望物化的并发问题?

Postgresql 来自渴望物化的并发问题?,postgresql,database-design,concurrency,Postgresql,Database Design,Concurrency,使用PostgreSQL 9.6.5,我不再使用内置的物化视图模型,因为它缺少增量刷新,并且出于我的目的(通过SymmetricDS复制),我实际上需要表存储中的数据,而不是视图。我的解决方案: 创建一个“非物质化视图”视图\u XXX\u UNMAT(实际上只是一个选择) 创建表格VIEW\u XXX,从VIEW\u XXX\u UNMAT中选择(快照) 将主键添加到视图\u XXX 创建一个刷新功能,根据主键从视图中删除并重新插入 为VIEW\u XXX\u UNMAT中涉及的每个表创建IN

使用PostgreSQL 9.6.5,我不再使用内置的
物化视图
模型,因为它缺少增量刷新,并且出于我的目的(通过SymmetricDS复制),我实际上需要表存储中的数据,而不是视图。我的解决方案:

  • 创建一个“非物质化视图”
    视图\u XXX\u UNMAT
    (实际上只是一个选择)
  • 创建表格
    VIEW\u XXX
    ,从
    VIEW\u XXX\u UNMAT
    中选择(快照)
  • 将主键添加到
    视图\u XXX
  • 创建一个刷新功能,根据主键从视图中删除并重新插入
  • VIEW\u XXX\u UNMAT
    中涉及的每个表创建
    INSERT
    /
    DELETE
    /
    UPDATE
    触发器,该触发器使用适当的PK调用刷新函数
  • 我的灵感来自这次演讲,一旦我们克服了创造所有这些触发器的障碍,一切都很好。显然,我们将
    UPDATE
    触发器限制在所涉及的列中,并且仅当
    NEW
    数据与
    OLD
    数据不同时才刷新视图

    在这一点上,我想知道:

  • 如果有更好的解决方案(扩展?),请记住我最终需要表
  • 性能问题(我知道刷新成本是写限制的,但是因为物化表是索引的,所以速度相当快?)
  • 并发性问题(如果两个人同时更新同一个字段,通过触发器刷新物化视图,其中一个人会失败还是MVCC会“处理好它”?)