Re: [HACKERS] Fixing matching of boolean index columns to sort ordering
От | David G. Johnston |
---|---|
Тема | Re: [HACKERS] Fixing matching of boolean index columns to sort ordering |
Дата | |
Msg-id | CAKFQuwacaXxBj3SMAaLAgdK6VoYfDnp87zd2QbuZHV8iKU47_g@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] Fixing matching of boolean index columns to sort ordering (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Fixing matching of boolean index columns to sort ordering
|
Список | pgsql-hackers |
Every WHERE clause is a
boolean expression, so there's no principled reason why such a rule
wouldn't result in canonicalizing e.g. "i = 42" into "(i = 42) = true",
wreaking havoc on every other optimization we have. Restricting it
to only apply to simple boolean columns is no answer because (a) indexes
can be on boolean expressions not just simple columns, and (b) part
of the point of the canonicalization is to make logically-equivalent
expressions look alike, so declining to apply it in some cases would
ruin that.
Given our reliance on operators in indexing a canonicalization rule that says all boolean yielding expressions must contain an operator would yield the desired result. "i = 42" already has an operator so no further normalization is necessary to make it conform to such a rule.
The indexing concern may still come into play here, I'm not familiar enough with indexes on column lists versus indexes on expressions to know off the top of my head. The definition of "looking alike" seems like it would be met since all such expression would look alike in having an operator.
That said, not adding "= true" is more visually appealing - though given all of the other things we do in ruleutils this seems like a minor addition.
David J.
В списке pgsql-hackers по дате отправления: