> This isn't a problem for operators found in operator families, because
> we trust those to not have undesirable side effects like raising
> data-dependent errors. But it'd be an issue if we started to apply
> quals that aren't index quals directly to index rows before doing
> the heap liveness ch
Hi All,
I'd like to report what seems to be a missing optimization opportunity or
understand why it is not possible to achieve.
TLDR; additional index column B specified in CREATE INDEX .. (A) INCLUDE(B) is
not used to filter rows in queries like WHERE B = $1 ORDER BY A during
IndexScan. https
> Perhaps this is what you mean by "deterministic", but isn't it
> possible for some collations to treat multiple byte sequences as equal
> values? And those multiple byte sequences wouldn't necessarily occur
> sequentially in C collation, so it wouldn't be possible to work around
> that by havin
Hi All,
It is known, that collation "C" significantly speeds up string comparisons and
as a result sorting. I was wondering, whether it is possible to use it
regardless of collation set on a column in sorts not visible to users?
Example I have in mind is sorting performed for GroupAggregate.
