Re: checking for a NULL date in a partitioned table kills performance

From: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
To: Doug Reynolds <mav(at)wastegate(dot)net>
Cc: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: checking for a NULL date in a partitioned table kills performance
Date: 2024-08-23 16:08:49
Message-ID: 9EE69544-3ADC-4882-89E8-3205278FEFC3@elevated-dev.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-performance

> On Aug 23, 2024, at 9:42 AM, Doug Reynolds <mav(at)wastegate(dot)net> wrote:
>
> The only difference is that you would be reading from one index instead of two, which could be more efficient.

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.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Craig Milhiser 2024-08-23 19:24:50 Is index deduplication active on an index
Previous Message Wetmore, Matthew (CTR) 2024-08-23 15:49:27 Re: checking for a NULL date in a partitioned table kills performance

Browse pgsql-performance by date

  From Date Subject
Previous Message Wetmore, Matthew (CTR) 2024-08-23 15:49:27 Re: checking for a NULL date in a partitioned table kills performance