[
https://issues.apache.org/jira/browse/CALCITE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Chen updated CALCITE-7807:
--------------------------------
Description:
{{SqlTypeFactoryImpl.createTypeWithCharsetAndCollation}} calls
{{BasicSqlType.createWithCharsetAndCollation}} for every {{BasicSqlType}}
input. When the type already has the requested charset and collation, it still
allocates an equivalent {{BasicSqlType}} and {{SerializableCharset}}, which
{{canonize}} then discards in favor of the existing interned instance.
This happens often during least-restrictive type inference over many character
literals, for example planning a large string {{IN}} list.
{{BasicSqlType.createWithCharsetAndCollation}} should return {{this}} when the
requested charset is equal and the collation is the same instance. Collations
are compared by identity because {{SqlCollation.equals}} ignores coercibility.
Requests that change either attribute keep the existing construction and
canonicalization path.
In Druid's string-IN planning benchmark
({{InPlanningBenchmark.queryStringInSqlPlanOnly}}, {{-prof gc}}), allocation
dropped by 9.05% at 100,000 literals and 8.72% at 1,000,000 literals. Timing
confidence intervals overlapped, so no latency improvement is claimed.
The omission of collation coercibility from type canonicalization is a
separate, pre-existing issue tracked in CALCITE-3953.
Pull request: [PR #5281|https://github.com/apache/calcite/pull/5281]
was:
{{SqlTypeFactoryImpl.createTypeWithCharsetAndCollation}} calls
{{BasicSqlType.createWithCharsetAndCollation}} for every {{BasicSqlType}}
input. When the type already has the requested charset and collation, it still
allocates an equivalent {{BasicSqlType}} and {{SerializableCharset}}, which
{{canonize}} then discards in favor of the existing interned instance.
This happens often during least-restrictive type inference over many character
literals, for example planning a large string {{IN}} list.
{{BasicSqlType.createWithCharsetAndCollation}} should return {{this}} when the
requested charset is equal and the collation is the same instance. Collations
are compared by identity because {{SqlCollation.equals}} ignores coercibility.
Requests that change either attribute keep the existing construction and
canonicalization path.
In Druid's string-IN planning benchmark
({{InPlanningBenchmark.queryStringInSqlPlanOnly}}, {{-prof gc}}), allocation
dropped by 9.05% at 100,000 literals and 8.72% at 1,000,000 literals. Timing
confidence intervals overlapped, so no latency improvement is claimed.
The omission of collation coercibility from type canonicalization is a
separate, pre-existing issue tracked in CALCITE-3953.
The isolated Druid benchmark reduced allocation by 9.05% at 100,000 string
literals and 8.72% at 1,000,000 string literals.
Pull request: [PR #5281|https://github.com/apache/calcite/pull/5281]
> BasicSqlType.createWithCharsetAndCollation should return this when charset
> and collation are unchanged
> ------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-7807
> URL: https://issues.apache.org/jira/browse/CALCITE-7807
> Project: Calcite
> Issue Type: Sub-task
> Reporter: Frank Chen
> Priority: Major
> Labels: pull-request-available
>
> {{SqlTypeFactoryImpl.createTypeWithCharsetAndCollation}} calls
> {{BasicSqlType.createWithCharsetAndCollation}} for every {{BasicSqlType}}
> input. When the type already has the requested charset and collation, it
> still allocates an equivalent {{BasicSqlType}} and {{SerializableCharset}},
> which {{canonize}} then discards in favor of the existing interned instance.
> This happens often during least-restrictive type inference over many
> character literals, for example planning a large string {{IN}} list.
> {{BasicSqlType.createWithCharsetAndCollation}} should return {{this}} when
> the requested charset is equal and the collation is the same instance.
> Collations are compared by identity because {{SqlCollation.equals}} ignores
> coercibility. Requests that change either attribute keep the existing
> construction and canonicalization path.
> In Druid's string-IN planning benchmark
> ({{InPlanningBenchmark.queryStringInSqlPlanOnly}}, {{-prof gc}}), allocation
> dropped by 9.05% at 100,000 literals and 8.72% at 1,000,000 literals. Timing
> confidence intervals overlapped, so no latency improvement is claimed.
> The omission of collation coercibility from type canonicalization is a
> separate, pre-existing issue tracked in CALCITE-3953.
> Pull request: [PR #5281|https://github.com/apache/calcite/pull/5281]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
