Understanding partial index selection

Hi!

I've got a query running periodically which has been degrading in
performance as time goes on. I'm hoping to better understand what the
contributing factors are.

Given a table with:
```
postgres=# \d message
Table "public.message"
Column | Type | Collation | Nullable |
Default
------------+--------------------------+-----------+----------+-----------------------------
id | character varying | C | not null |
created_at | timestamp with time zone | | not null |
org_id | character varying | C | not null |
app_id | character varying | C | not null |
event_type | character varying | | not null |
uid | character varying | | |
payload | jsonb | | |
channels | jsonb | | |
expiration | timestamp with time zone | | not null | now() + '90
days'::interval
Indexes:
"pk_message" PRIMARY KEY, btree (id)
"ix_message_per_app" btree (app_id, id DESC)
"ix_message_uid_unique_app_cond" UNIQUE, btree (app_id, uid) WHERE uid
IS NOT NULL
"message_payload_not_null_pidx" btree (expiration) WHERE payload IS NOT
NULL
Foreign-key constraints:
"fk_message_app_id_application" FOREIGN KEY (app_id) REFERENCES
application(id) ON DELETE CASCADE
Referenced by:
TABLE "messagedestination" CONSTRAINT
"fk_messagedestination_msg_id_message" FOREIGN KEY (msg_id) REFERENCES
message(id) ON DELETE CASCADE
```

I periodically run a query like this:
```
UPDATE message SET payload = NULL WHERE id IN (
SELECT id FROM message
WHERE
payload IS NOT NULL
AND expiration <= now()
LIMIT 5000
FOR UPDATE SKIP LOCKED
);
```

The aim is to cull payload values after the retention period has expired.
The hope is the sub-select would leverage the index
"message_payload_not_null_pidx" but when I `EXPLAIN ANALYZE` the query, I
see a seq scan instead.

```
Update on message (cost=1773.41..44611.36 rows=5000 width=283) (actual
time=20913.192..20913.194 rows=0 loops=1)
-> Nested Loop (cost=1773.41..44611.36 rows=5000 width=283) (actual
time=20881.320..20886.541 rows=51 loops=1)
-> HashAggregate (cost=1772.85..1822.85 rows=5000 width=88)
(actual time=20881.286..20882.052 rows=51 loops=1)
Group Key: ("ANY_subquery".id)::text
-> Subquery Scan on "ANY_subquery" (cost=0.00..1760.35
rows=5000 width=88) (actual time=8425.022..20881.244 rows=51 loops=1)
-> Limit (cost=0.00..1710.35 rows=5000 width=38)
(actual time=8425.017..20881.219 rows=51 loops=1)
-> LockRows (cost=0.00..2112304.92 rows=6175068
width=38) (actual time=8425.016..20881.212 rows=51 loops=1)
-> Seq Scan on message message_1
(cost=0.00..2050554.24 rows=6175068 width=38) (actual
time=8424.977..20880.945 rows=65 loops=1)
Filter: ((payload IS NOT NULL) AND
(expiration <= now()))
Rows Removed by Filter: 37772897
-> Index Scan using pk_message on message (cost=0.56..8.56 rows=1
width=191) (actual time=0.073..0.073 rows=1 loops=51)
Index Cond: ((id)::text = ("ANY_subquery".id)::text)
Planning Time: 0.237 ms
Execution Time: 20913.310 ms
```

I have read that the planner's index preference is driven by statistics. I
looked at the correlation of both the expiration and payload columns, ~0.8
and ~0.4 respectively. I understand the planner prefers indices where the
correlation is farther from 0 (closer to the min/max of the -1, 1 range),
but I'm not sure where the threshold might be. Still, 0.4-ish feels low to
me.

I wonder if the fact the index is partial using `WHERE payload IS NOT NULL`
combined with the fact we're changing the value to NULL is sort of
"punching holes" in the index, reducing correlation over time. I'm not sure
how to test or prove this is the case.

I also wonder if the index type (btree) is inappropriate for some reason,
or what other factors I should be thinking about here.

Separately, I saw this earlier thread which describes a somewhat similar
problem, though the details are somewhat different.
https://www.postgresql.org/message-id/20230119090425.GA8608%40arp.lijzij.de

Perhaps all I'd need is to `CREATE STATISTICS` on these two columns to make
the index viable again.

I hope to just get a better understanding of what's going on. There's an
upcoming change to the schema which will likely sidestep this situation,
but there's still a lesson to learn here.

Thanks,
Owen