partial index是一个好主意，可以排除表中明显不需要的一半行。更简单：

CREATE INDEX name_idx ON table (text_col)
WHERE text_col IS NOT NULL;

字符串
在创建索引后运行ANALYZE table。（如果您不手动执行，autovacuum会在一段时间后自动执行，但如果您在创建后立即进行测试，则测试将失败。）
然后，为了说服查询规划器可以使用特定的部分索引，在查询中重复WHERE条件-即使它看起来多余：

SELECT col1,col2, .. colN
FROM   table 
WHERE  text_col = 'my_value'
AND   text_col IS NOT NULL;  -- repeat condition

型
The manual：
但是，请记住， predicate 必须匹配应该从索引中受益的查询中使用的条件。只有当系统可以识别查询的WHERE条件在数学上暗示索引的 predicate 时，才可以在查询中使用部分索引。PostgreSQL没有复杂的定理证明器，可以识别数学上等价的表达式，以不同的形式书写。（不仅创建这样一个通用的定理证明器极其困难，而且它可能太慢而不能有任何真实的用途。）该系统可以识别简单的不等式含义，例如“x < 1”意味着“x < 2”;否则， predicate 条件必须完全匹配查询的WHERE条件的一部分，否则索引将无法被识别为可用。因此，参数化查询子句不适用于部分索引。
对于参数化查询：同样，添加部分索引的（冗余） predicate 作为额外的常量WHERE条件，它工作得很好。

**更新：**Postgres 9.6或更高版本大大提高了index-only scans的机会。请参阅：

• PostgreSQL not using index during count(*)的

在仔细查看analyze帮助构建的pg_stats视图时，我在documentation上发现了这段摘录。

关联

列值的物理行排序和逻辑排序之间的统计相关性。范围从-1到+1。当值接近-1或+1时，由于减少了对磁盘的随机访问，估计对列的索引扫描比接近零时更便宜。（如果列数据类型没有<运算符，则此列为空。）
在我的本地机器上，相关数是0.97，而在生产环境中，相关数是0.05。因此，规划器估计，顺序遍历所有这些行比每次查找索引并在磁盘块上进行随机访问更容易。这是我用来查看相关数的查询。

select * from pg_stats where tablename = 'table_name' and attname = 'text_col';

字符串
此表还对其行执行了一些更新。行的avg_width估计为20字节。如果更新的文本列值很大，则可能会超过平均值，并且也会导致更新速度较慢。我的猜测是，每次更新都会使物理和逻辑顺序变得缓慢。为了解决这个问题，我执行了以下查询。

ALTER TABLE table_name SET (FILLFACTOR = 80);
VACUUM FULL table_name;
REINDEX TABLE table_name;
ANALYZE table_name;

型
这个想法是，我可以给每个磁盘块给予20%的缓冲区和vacuum full表，以回收丢失的空间并维护物理和逻辑顺序。

查询

explain analyze SELECT col1,col2... colN
FROM table_name 
WHERE text_col is not null 
AND 
text_col = 'my_value';

型

部分索引扫描- 1.5ms

Index Scan using tango on two (cost=0.000..165.290 rows=40 width=339) (actual time=0.083..0.086 rows=1 loops=1)
Index Cond: ((victor five NOT NULL) AND (victor = 'delta'::text))

型
排除NULL条件将使用位图堆扫描拾取其他索引。

全索引- 0.08ms

Bitmap Heap Scan on two  (cost=5.380..392.150 rows=98 width=339) (actual time=0.038..0.039 rows=1 loops=1)
    Recheck Cond: (victor = 'delta'::text)
  ->  Bitmap Index Scan on tango  (cost=0.000..5.360 rows=98 width=0) (actual time=0.029..0.029 rows=1 loops=1)
          Index Cond: (victor = 'delta'::text)

型

[编辑]

虽然最初看起来correlation在选择索引扫描方面起着重要作用，但@Mike观察到，他的数据库中接近0的correlation值仍然会导致索引扫描。更改填充因子和完全清空有帮助，但我不确定为什么。

只有当WHERE条件匹配时才使用部分索引。因此，只有当您在SELECT中使用相同条件时，才可以使用WHERE text_col IS NOT NULL索引。排序规则不匹配也可能导致损害。
请尝试以下操作：
1.创建一个最简单的btree索引CREATE INDEX foo ON table (text_col)

1. ANALYZE table个
   1.查询