Changes between Version 3 and Version 4 of Ticket #35778, comment 11


Ignore:
Timestamp:
Oct 2, 2024, 12:13:59 PM (6 weeks ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35778, comment 11

    v3 v4  
    1515Then 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.
    1616
    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.
     17If 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
     19From 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.
Back to Top