[
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.
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]
was:
Large string ARRAY validation repeatedly combines compatible character types.
The least-restrictive path may call createTypeWithCharsetAndCollation even when
the current immutable BasicSqlType already has the requested charset and
collation.
Return the existing BasicSqlType immediately when the requested charset and
collation are unchanged. Requests that change either attribute retain the
existing construction and canonicalization path.
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.
> 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]
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
