Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: checking for a NULL date in a partitioned table kills performance
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: 
 <010001917fe71552-589dbc9b-2c78-4a0d-8405-040db3cc09d7-000000@email.amazonses.com>
Date: Fri, 23 Aug 2024 10:08:49 -0600
Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9EE69544-3ADC-4882-89E8-3205278FEFC3@elevated-dev.com>
References: <1F2BA008-3732-4289-876A-EF6889474E08@elevated-dev.com>
 <010001917fe71552-589dbc9b-2c78-4a0d-8405-040db3cc09d7-000000@email.amazonses.com>
To: Doug Reynolds <mav@wastegate.net>
Archived-At: 
 <https://www.postgresql.org/message-id/9EE69544-3ADC-4882-89E8-3205278FEFC3%40elevated-dev.com>
Precedence: bulk

> On Aug 23, 2024, at 9:42=E2=80=AFAM, Doug Reynolds <mav@wastegate.net> =
wrote:
>=20
> The only difference is that you would be reading from one index =
instead of two, which could be more efficient.=20

Ah yes, that's a good point to take into consideration in such a case.

In the one at hand though, if statistics are correct, neither index is =
going to be used, given the 90% of rows with NULL values. Using an index =
would just waste time compared to a simple sequential scan.=