也许这是一个愚蠢的初学者问题，但我在任何地方都找不到答案。我到处都读到了Transaction Isolation解决并发事务中数据可见性的方法。我关心的是单个事务中的行为。
如果我开始一个事务，插入一些数据，我是否能够在之后立即选择它们 - 仍然在同一个但未提交的事务中？如果是，在并发事务的情况下，这种行为是否可以像提到的事务隔离一样以类似的方式改变？
具体来说，我的目标是 PostgreSQL 9.4。
使用 Postgres 9.4，我经常执行以下查询：
SELECT DISTINCT ON(recipient) * FROM messages
LEFT JOIN identities ON messages.recipient = identities.name
WHERE timestamp BETWEEN timeA AND timeB
ORDER BY recipient, timestamp DESC;
所以我决定创建一个视图：
CREATE VIEW myView AS SELECT DISTINCT ON(recipient) * FROM messages
LEFT JOIN identities ON messages.recipient = identities.name
ORDER BY recipient, timestamp DESC;
我刚刚意识到，如果我查询我的观点，就像SELECT * FROM myView WHERE timestamp BETWEEN timeA AND timeB我的表现要差很多一样。
这样EXPLAIN ANALYZE两个问题，我发现了原因是，在第二种情况下，数据库带来了所有记录，请问左连接，然后应用WHERE条款。换句话说，WHERE子句不会被下推到视图的查询中。我还尝试ORDER BY从视图中删除，但数据库仍然LEFT JOIN对完整数据而不是过滤集执行。
这种行为的原因是什么？有没有办法在使用视图时获得可比较的性能？
我有一个包含数百万行的表，分为几个类别（比如数字 1-5）。访问数据库的应用程序使用一个单一的数据库帐户。但是，该应用程序有自己的用户帐户，每个应用程序用户只能访问某些类别。因此，允许的类别列表通过会话变量传递给数据库：
SET SESSION mydb.allowed_categories = '1,3,5';
我使用 RLS 根据会话变量过滤行：
CREATE POLICY table_select_policy ON big_table
FOR SELECT
USING (ARRAY[category] && string_to_array(current_setting('mydb.allowed_categories'),',')::int[]));
问题在于，使用这种方法，RLS 行过滤需要花费大量时间。另一方面，当我通过以下方式进行实验时：
CREATE POLICY table_select_policy ON big_table
FOR SELECT
USING (category = 1 OR category = 3 OR category = 5);
RLS 过滤几乎快了 10 倍。当然，这种硬编码是行不通的，因为我想在应用程序中动态更改允许的类别列表。
这 category列有一个 btree 索引，但是由于类别的数量相当少，查询计划器总是倾向于对 RLS 过滤器进行顺序扫描。
所以我的问题是 - 有没有办法优化 RLS 表达式，使其至少更接近硬编码方法？你会建议一个不同的解决方案吗？该应用程序有很多用户，所以我不想为每个用户都创建一个数据库帐户。