Changes between Version 3 and Version 4 of Ticket #35778, comment 11
- Timestamp:
- Oct 2, 2024, 12:13:59 PM (7 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #35778, comment 11
v3 v4 15 15 Then the resulting index will be on `(phone_number)::text` and queries of the form `filter(phone_number__startswith="123")` will generate `WHERE (phone_number)::text LIKE '123%'` will be able to use the index. 16 16 17 If we change `Cast` to use `CAST` instead of `::` I'm not entirely confident that the Postgres planer will be smart enough to use the pre-existing `(phone_number)::text` it for queries of the form `CAST(phone_number AS text) LIKE '123%'`. From past experience the expression has to exactly match for the planner to consider the index as potential candidate so unless `(expr)::type` and `CAST(expr AS type)` result in the same AST I doubt we can safely change it without forcing users to rebuild all of their indices making use of `Cast` which seems way beyond the scope of this ticket. 17 If we change `Cast` to use `CAST` instead of `::` I'm not entirely confident that the Postgres planer will be smart enough to use the pre-existing `(phone_number)::text` index for queries of the form `CAST(phone_number AS text) LIKE '123%'`. 18 19 From past experience the expression has to exactly match for the planner to consider the index as potential candidate so unless `(expr)::type` and `CAST(expr AS type)` result in the same AST I doubt we can safely change it without forcing users to rebuild all of their indices making use of `Cast` which seems way beyond the scope of this ticket.