PostgreSQL 9.6查看性能和副作用

Question

我们的项目使用不同的架构来保持事物的组织性和安全性。 我们GRANT访问整个架构而不是选择这可能导致数据的无意泄漏单个组件。 此外，如果我们可以从单个模式编写查询，这将使我们的生活更加轻松，因为这将有助于维护和减少错误。

例如， schema_foo和schema_bar包含原始规范化数据（最终用户无法访问），而schema_baz包含从schema_foo和schema_bar返回数据的函数（最终用户可以访问）。 当schema_foo和schema_bar数据需要在交付给最终用户之前进行处理时， schema_foo schema_bar 。 但是，在某些情况下，不需要其他处理。

在这种情况下，在schema_baz仅通过调用schema_foo或schema_bar的表来创建视图是否schema_bar ，如果这样，两者之间的性能差异/副作用是什么？

SELECT * FROM schema_foo.table_bin;

和

CREATE VIEW schema_baz.view_bin AS SELECT * FROM schema_foo.table_bin;
SELECT * schema_baz.view_bin;

如果可以接受，那么通过名称而不是*标识每个列是否更好（出于任何原因）？

注意：结果视图也将在其他查询中使用。 我知道查询计划器很棒； 但是，我担心（滥用）仅出于使表可从另一模式访问的目的而使用视图可能会产生意想不到的后果。

Answer 1

我的经验倾向于“如有疑问，请明确表达”。 在生产系统中使用select *通常只是在寻求麻烦。

同样，在Postgres中将列添加到基表中也不会更改视图中的列-它们不会神奇地出现。 举个例子：

(postgres@lh:5432) # create table foo (col1 integer, col2 text);
CREATE TABLE

(postgres@lh:5432) # create view bar as select * from foo;
CREATE VIEW

(postgres@lh:5432) # alter table foo add col3 date;
ALTER TABLE

(postgres@lh:5432) # insert into foo values (1, 'One', current_date);
INSERT 0 1

(postgres@lh:5432) [~] # select * from foo;
 col1 | col2 |    col3    
------+------+------------
    1 | One  | 2017-08-17
(1 row)

(postgres@lh:5432) # select * from bar;
 col1 | col2 
------+------
    1 | One
(1 row)

这是9.5版，但如果其他版本的工作方式有所不同，我会感到惊讶。

Answer 2

是的，表可以而且确实经常改变。 如果您只写*，那么如果在基表中添加或删除列怎么办？ 您的视图在您不知情的情况下发生了变化。

最佳做法是在编写任何类型的视图时始终列出列名称。