使用以下WHERE个谓词来考虑SQL查询:
...
WHERE name IS NOT NULL
...
其中name是PostgreSQL中的文本字段.
其他任何查询都不会判断该值的任何文本属性，不管它是否为NULL.因此，尽管it supports this distinction:
此外，索引列上的IS NULL或IS NOT NULL条件可以与B树索引一起使用.
What's the right PostgreSQL index to quickly distinguish 100s from non-100s?
我是在解释你所说的在两个方面"过火"的说法:在复杂性方面(使用B-树而不仅仅是列表)和空间/性能方面.
就复杂性而言，这并不过分.B树索引更可取，因为它的deletes比某种"无序"索引更快(因为缺少更好的术语).(无序索引需要进行完整的索引扫描才能删除.)鉴于这一事实，无序指数带来的任何yield 通常都会被不利因素所抵消，因此开发工作是不合理的.
不过，就空间和性能而言，如果你想要一个高效的高 Select 性索引，你可以在索引中加入WHERE子句，如fine manual:
CREATE INDEX ON my_table (name) WHERE name IS NOT NULL;
请注意，只有在执行查询时允许PostgreSQL忽略large行的情况下，您才能看到此索引的好处.例如，如果99%的行中有name IS NOT NULL行，那么索引不会给你带来任何好处，而仅仅是允许进行完整的表扫描；事实上，由于需要额外的磁盘读取，它的效率会更低(如@CraigRinger条注释).然而，如果只有1%的行有name IS NOT NULL行，那么这意味着巨大的节约，因为PostgreSQL可以忽略查询中的大部分表.如果您的表非常大，即使删除50%的行也可能是值得的.这是一个调整问题，索引是否有价值将在很大程度上取决于数据的大小和分布.
此外，如果仍然需要为name IS NULL行创建另一个索引，那么在空间方面几乎没有什么好处.详情见Craig Ringer's answer.