我有很多看起来像这样的表格：
CREATE TABLE table1(id INTEGER PRIMARY KEY, t1c1 INTEGER, t1c2 INTEGER);
CREATE TABLE table2(id INTEGER PRIMARY KEY, t1 INTEGER REFERENCES table1(id), t2c1 INTEGER);
我做了很多连接，我试图过滤连接表以从第一个表中获取内容，如下所示：
SELECT t1c1
FROM table1
JOIN table2 ON table2.t1 = table1.id
WHERE t2c1 = 42;
当我为表编写索引时，我会查看 WHERE 子句中使用的列并构建索引以满足它们。所以对于这个查询，我最终会写一个这样的索引：
CREATE INDEX ON table2 (t2c1);
并且这个索引至少有资格在该查询中使用。
我的问题是，如果我写这样的索引：
CREATE INDEX ON table2 (t2c1, t1);
索引会不会作为覆盖索引来帮助上面查询中的JOIN？我应该改变我的索引编写策略来覆盖外键列吗？
我在文档中看到了count(*)和之间的区别count(pk)。我一直在使用count(pk)（哪里pk是SERIAL PRIMARY KEY）不知道count(*).
我的问题是关于 Postgres 的内部优化。是否足够聪明地发现 aSERIAL PRIMARY KEY将存在于每一行中并且永远不会为假并且只计算行数，或者它是否会对每一行进行冗余谓词检查？我同意这可能是一个毫无意义的优化，但我只是好奇。
我看了看输出EXPLAIN和EXPLAIN VERBOSE为count(*)，count(id)并count(id > 50)看看是否EXPLAIN提到检查其输出的断言。它没有。