重复Django过滤条件为何会改变PostgreSQL的查询计划估算？

先给你逐个拆解这三个问题，结合你遇到的实际场景来解释：

1. PostgreSQL遇到重复的WHERE条件时，真的会把选择性相乘吗？ #

对的，这种情况确实会发生。核心原因是：PostgreSQL的查询优化器默认会把每个条件当成独立的过滤步骤，除非它能明确识别出两个条件是完全等价的并自动合并。但像你这种包含多表关联、多层OR组合的复杂条件，优化器大概率没检测到这两个条件是一模一样的，所以就会把两次过滤的选择性直接相乘。

比如你原来的单个过滤条件能保留1/3的行数（对应选择性≈0.33），重复一次后优化器就会按0.33×0.33≈0.11来算，估算行数就变成原来的1/3左右——刚好和你看到的7200→2400的结果对应上。

2. PostgreSQL在这种场景下是怎么计算选择性的？ #

PostgreSQL的选择性估算逻辑分两步：

• 首先，对于单个简单条件（比如delay_field IS NULL、timestamp_field <= TIMESTAMP），它会依赖表的统计信息（比如列的唯一值数量、直方图数据）来估算能保留多少行。
• 对于像你这种多层OR+AND的复杂组合条件，它会先算出每个子条件的选择性，再用概率公式（比如OR条件用P(A)+P(B)-P(A∩B)）算出整个组合条件的总选择性S。

当你重复整个复杂条件时，优化器没认出这和之前的条件是等价的，就会把总选择性再乘一次S，最终的估算行数就变成总行数 × S × S——这就是为什么估算行数会骤降的原因。

3. 不用重复过滤条件，怎么让优化器得到更准确的低行数估算？ #

给你几个实际可落地的方法，都是Django+PostgreSQL环境下能用的：

• 补全/更新统计信息：PostgreSQL的估算不准很多时候是因为统计信息不够详细。你可以针对过滤用到的列手动执行ANALYZE main_table (delay_field, tenant_id);（替换成你实际的表和列），或者调大default_statistics_target参数（比如从100改成1000），让PostgreSQL收集更细粒度的统计数据，这样单个条件的选择性估算就会更准确，不需要靠重复条件来“凑”结果。
• 用CTE物化过滤结果：在Django 3.2及以上版本，你可以把过滤后的查询包装成物化CTE，让PostgreSQL先执行过滤并把结果落地，后续步骤基于这个物化后的结果来估算行数。比如修改你的get_custom_filter：

  from django.db.models import Q
  from django.utils import timezone
  
  def get_custom_filter(qs):
      filtered_qs = qs.filter(
          Q(
              Q(timestamp_field__lte=timezone.now(), related_obj__delay__isnull=True)
              | Q(related_obj__delay__lte=timezone.now(), type_obj__flag=False, timestamp_field__isnull=False)
              | Q(type_obj__flag=True, timestamp_field__lte=timezone.now())
          )
      )
      # 把过滤结果转为物化CTE
      cte = filtered_qs.with_cte('filtered_cte', materialized=True)
      # 基于CTE的主键查询原表
      return qs.filter(pk__in=cte.values('pk'))
  

  这样PostgreSQL会先执行CTE的过滤，然后基于CTE的实际（或更准确的估算）行数来处理后续的排序、去重等操作。
• 用子查询提前固化过滤结果：如果你的Django版本不支持CTE，也可以用子查询的方式，比如：

  from django.db.models import Q
  from django.utils import timezone
  
  def get_custom_filter(qs):
      # 先通过子查询获取符合条件的主键
      valid_pks = qs.filter(
          Q(
              Q(timestamp_field__lte=timezone.now(), related_obj__delay__isnull=True)
              | Q(related_obj__delay__lte=timezone.now(), type_obj__flag=False, timestamp_field__isnull=False)
              | Q(type_obj__flag=True, timestamp_field__lte=timezone.now())
          )
      ).values('pk')
      # 用主键过滤原查询集
      return qs.filter(pk__in=valid_pks)
  

  这种方式会让PostgreSQL先执行子查询得到过滤后的主键列表，再基于这个列表来查询，估算行数会更贴近实际。
• 调整查询语句结构：把复杂的OR条件尽量拆成更易被优化器识别的形式，比如把跨表的条件提前用annotate关联到主表，或者用Exists子查询替代部分OR逻辑，让优化器更容易准确估算选择性。

备注：内容来源于stack exchange，提问作者Tsygankov Alexander