From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Remove redundant NULL check in clause_selectivity_ext() function |
Date: | 2024-08-19 09:38:05 |
Message-ID: | 016e33b7-2830-4300-bc89-e7ce9e613bad@tantorlabs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi everyone,
In the `clause_selectivity_ext()` function, there’s a comment regarding
a NULL clause check that asks, "can this still happen?". I decided to
investigate whether this scenario is still valid.
Here’s what I found after reviewing the relevant cases:
- approx_tuple_count(): The function iterates over a loop of other clauses.
- get_foreign_key_join_selectivity(): The function is invoked within an
`if (clause)` condition.
- consider_new_or_clause(): The clause is generated by
`make_restrictinfo()`, which never returns NULL.
- clauselist_selectivity_ext(): This function either checks
`list_length(clauses) == 1` before being called, or it is called within
a loop of clauses.
In other cases, the function is called recursively from
`clause_selectivity_ext()`.
If you are aware of any situations where a NULL clause could be passed
or if I’ve missed anything, please let me know. I’m also open to any
other suggestions.
--
Regards,
Ilia Evdokimov,
Tantor Labs LCC.
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Remove-redundant-NULL-check-for-clause-during-select.patch | text/x-patch | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-08-19 09:43:06 | Re: thread-safety: gmtime_r(), localtime_r() |
Previous Message | shveta malik | 2024-08-19 09:33:03 | Re: Conflict detection and logging in logical replication |