From: | Doug Reynolds <mav(at)wastegate(dot)net> |
---|---|
To: | 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 15:42:16 |
Message-ID: | 010001917fe71552-589dbc9b-2c78-4a0d-8405-040db3cc09d7-000000@email.amazonses.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-performance |
The only difference is that you would be reading from one index instead of two, which could be more efficient.
Sent from my iPhone
> On Aug 23, 2024, at 11:19 AM, Scott Ribe <scott_ribe(at)elevated-dev(dot)com> wrote:
>
>
>>
>> On Aug 23, 2024, at 5:39 AM, Doug Reynolds <mav(at)wastegate(dot)net> wrote:
>>
>> You could try something really ugly where you make a function index that COALESCEs the nulls to 1-1-1900 and use the COALESCE in the query.
>
> I don't see how that could be better than just creating a partial index on it WHERE contract_date IS NULL--and anyway I'm sure you're right that no index would help. No matter what, it seems that sequential scans of all partitions will be required since most rows have it null, and it's not even related to the partition key.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Wetmore, Matthew (CTR) | 2024-08-23 15:49:27 | Re: checking for a NULL date in a partitioned table kills performance |
Previous Message | Scott Ribe | 2024-08-23 15:17:19 | Re: checking for a NULL date in a partitioned table kills performance |
From | Date | Subject | |
---|---|---|---|
Next Message | Wetmore, Matthew (CTR) | 2024-08-23 15:49:27 | Re: checking for a NULL date in a partitioned table kills performance |
Previous Message | Scott Ribe | 2024-08-23 15:17:19 | Re: checking for a NULL date in a partitioned table kills performance |