Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tOKhY-005duL-33 for pgsql-performance@arkaria.postgresql.org; Thu, 19 Dec 2024 17:52:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tOKhW-00FaJY-JF for pgsql-performance@arkaria.postgresql.org; Thu, 19 Dec 2024 17:52:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tOKhW-00FaJJ-9D for pgsql-performance@lists.postgresql.org; Thu, 19 Dec 2024 17:52:42 +0000 Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tOKhT-000Pzr-Ic for pgsql-performance@lists.postgresql.org; Thu, 19 Dec 2024 17:52:40 +0000 Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-8019338c2b2so630546a12.3 for ; Thu, 19 Dec 2024 09:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734630758; x=1735235558; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=vHsN57dUvrjdwP7HYbkM9smelToi3c0uqEQV/2yOAE0=; b=IVxJrq13l2B4TP74GXo7jn0b4NPkNBTqR0Q6LDBXlE17gVQHuI0TY5D+nyGGWVx+qf a+O+1Q/JQ1UgS+eQOTWoQ7x51EA841IenS7/3VlAVo/bc1Hu7NpboLI/EGt3LHeIvDHq Tv0WjnnREzXzGRgZiU5XbS7v48/bN/3RXph73kcvK1DsLYZWJSNUHzkoC/XTmE2wgfZw JF77zmhXDxRjOsKSNZ/OL9p9Gq8CEsOvzu/NzdyIIDlDJvk/RX4MQiyyOVx7zRfcjFwZ HTVWH47MLBGe/oHHUTSgCVO4smouAvOAmY23h8BrkFrnMF1mxo2OfIIrZatNedEsmuf/ 5AVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734630758; x=1735235558; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=vHsN57dUvrjdwP7HYbkM9smelToi3c0uqEQV/2yOAE0=; b=I/kvabvUkzCQc4ILQfDDt5LBnIUPWI4OZ2jpuj1ezhIDfvQ5HVFzDwN6kEP3UuTJpn J+5m4nwm1hr+RzyxgmpSpzOKz2tUCSsl5PkeNyC1ks40LikY4ufED22Y0PSNQXcFcVkn G5zh64uT3lbCGUJQuteB5yaodhr0luwDTd9wC/uxeTiKILzUdhwB9LPdQtuNYfZWNGBd mZBVg6dyZKJRxYRieG+rqAMpS4uBl3pT22hasK7tU4wgXPgZvzGWitjhVTJDUyt2uP7z ChspZikyufTkrWWQQ+ik9xYE4nczWKEHL/qrVsXzbbIwNDtoskvWniQs2YLm/TBKrOqE ncyw== X-Gm-Message-State: AOJu0Yw6GoP+TbRmZ2qfokFSl33WNp8bnEJKGdKn6BkLDhJbSsMyTZ/B ID+tRsY3afR52jCY484GcmB9aWmNzVGiFkqLmjol+sAlG0gSPkkGf8DyHQLLb1tfjZdDJNA7nfK 422ZT5mRtJ9yjTOtfdNj/aB7MmFDo4sM/ X-Gm-Gg: ASbGncuYVpHrmFrvsyVy6SpuRSEGdBu6mnDthsT7CEUHRLWX8uIY5uFkktSw0Kkzj+Y 4RxhqXzPWXBiGUHUg27B8iyPf7shAzFOiEgKx X-Google-Smtp-Source: AGHT+IFkJpQlwY0VTCYIOUs226SBIHL3zHsGFL9637rr3J39W2f8JjXtkQ0Uzw5KMmiiM3kydHlAu+pB6hmtfWCJESA= X-Received: by 2002:a17:90b:524f:b0:2ee:e961:303d with SMTP id 98e67ed59e1d1-2f443d58fa5mr6265044a91.35.1734630758232; Thu, 19 Dec 2024 09:52:38 -0800 (PST) MIME-Version: 1.0 From: Jon Zeppieri Date: Thu, 19 Dec 2024 12:52:27 -0500 Message-ID: Subject: Why a bitmap scan in this case? To: pgsql-performance@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I'm trying to speed up a particular query, so I tried out a very specific index meant to target this one query alone. (I'm not at all convinced that's a good idea, but I'm curious to see just how fast I can make this one query.) The index is like this: create index idx_foo on my_tbl (start_on) where end_on is null and bar_id is null and population_kind = 2; The query needs to find rows that are before a certain start_on date where all of the `where` conditions listed in the index are satisfied. The query planner insists on using the index to do a bitmap scan: ``` db=# explain select start_on from my_tbl where end_on is null and bar_id is null and population_kind = 2 and start_on < '2024-11-07'; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------- Bitmap Heap Scan on my_tbl (cost=1116.28..329938.13 rows=317919 width=4) Recheck Cond: ((start_on < '2024-11-07'::date) AND (end_on IS NULL) AND (bar_id IS NULL) AND (population_kind = 2)) -> Bitmap Index Scan on idx_foo (cost=0.00..1036.81 rows=317919 width=0) Index Cond: (start_on < '2024-11-07'::date) JIT: Functions: 2 Options: Inlining false, Optimization false, Expressions true, Deforming true (7 rows) ``` Why wouldn't it do an index (or, really, an index only) scan in this case, given that the index contains exactly the data that the query needs? I'm running PG 16.4. - Jon