[
https://issues.apache.org/jira/browse/CALCITE-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108395#comment-17108395
]
Jesus Camacho Rodriguez edited comment on CALCITE-3999 at 5/15/20, 3:40 PM:
----------------------------------------------------------------------------
Thanks for looking in detail into this [~zabetak].
{quote}
Moreover, most of the methods in DatabaseMetaData just return some hardcoded
values so there are no real queries to the database.
{quote}
I checked a few drivers, and while this is true for most of the calls that we
make to create the dialect, I realized that {{getDatabaseProductVersion}} may
still emit a query to the RDBMS in multiple implementations.
>From the top of my head, a few scenarios where I guess the cache may be useful:
- Multitenant deployments with many connections to same RDBMS.
- Reduce latency under network congestion.
- Reduce compilation latency variability (memory vs network access).
What do you think about these? There is probably a trade-off here, but I think
it is not straightforward to simulate all the possible different scenarios.
was (Author: jcamachorodriguez):
Thanks for looking in detail into this [~zabetak].
>From the top of my head, a few scenarios where I guess the cache may be useful:
- Multitenant deployments with many connections to same RDBMS.
- Reduce latency under network congestion.
- Reduce compilation latency variability (memory vs network access).
What do you think about these? There is probably a trade-off here, but I think
it is not straightforward to simulate all the possible different scenarios.
> Simplify DialectPool implementation using Guava cache
> -----------------------------------------------------
>
> Key: CALCITE-3999
> URL: https://issues.apache.org/jira/browse/CALCITE-3999
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JdbcUtils contains a pool to cache SqlDialect objects. Currently, it relies
> on multiple maps and a synchronized {{get}} method. Although I am not very
> familiar with that code, it seems the implementation could be made simpler
> and more efficient by using a Guava cache. In addition, since we would not
> have a single synchronized get method, multiple threads could concurrently
> create dialects for distinct data sources.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
