Re: Question about babel
This has nothing to do with Javascript. Babel is a SQL parser in Calcite that is designed to be as permissive as possible. While the default Calcite parser attempts to adhere to SQL standards, the goal of the Babel parser is to accept as much as possible across varying dialects of SQL. -- Michael Mior mm...@apache.org Le sam. 11 juin 2022 à 03:13, junww2...@gmail.com a écrit : > Hi, > > In Calcite source code, there is a package called SQL.parser.babel. What is > the package for? Is it for this parser? > https://babeljs.io/docs/en/babel-parser > > Thanks, > > Jack >
Question about babel
Hi, In Calcite source code, there is a package called SQL.parser.babel. What is the package for? Is it for this parser? https://babeljs.io/docs/en/babel-parser Thanks, Jack
[jira] [Created] (CALCITE-5189) Add support for constant HTTP path prefixes to Avatica server
Will Noble created CALCITE-5189:
---
Summary: Add support for constant HTTP path prefixes to Avatica
server
Key: CALCITE-5189
URL: https://issues.apache.org/jira/browse/CALCITE-5189
Project: Calcite
Issue Type: New Feature
Components: avatica
Reporter: Will Noble
Assignee: Will Noble
Some load balancers, such as those based on [Kubernetes ingress
rules|https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#httpingressrulevalue-v1beta1-networking-k8s-io],
can only route requests based on HTTP path. To support hosting an Avatica
server behind such a load balancers, the driver should support prepending all
HTTP request paths with a constant (configurable) prefix, and the server should
support stripping that constant prefix from all requests is receives.
On the server side, this can either be done as a piece of middleware (A handler
wrapper that just strips the prefix then delegates to the real handler), or by
modifying the existing 2 handlers ({{AvaticaProtobufHandler}} and
{{AvaticaJsonHandler}}) to ignore the prefix (without duplicating code). I'm
leaning toward the former, since it would obviate the need to worry about it in
any custom / future handlers.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
Re: [jira] [Created] (CALCITE-5187) "CalciteSchema call getSubSchemaMap when prepareSql" will Causes SQL execution to slow down
Out of curiosity, why are you recalculating subschemas on queries?
It seems like you might be able to cache the schema information on initial
source add, and then use DB event triggers to cause a recalculation on
schema change
On Thu, Jun 9, 2022 at 11:25 PM itxiangkui (Jira) wrote:
> itxiangkui created CALCITE-5187:
> ---
>
> Summary: "CalciteSchema call getSubSchemaMap when prepareSql"
> will Causes SQL execution to slow down
> Key: CALCITE-5187
> URL: https://issues.apache.org/jira/browse/CALCITE-5187
> Project: Calcite
> Issue Type: Improvement
> Reporter: itxiangkui
> Attachments: Screenshot from 2022-06-10 11-17-02.png, Screenshot
> from 2022-06-10 11-18-54.png
>
>
>
>
> # We define the structure of Schema-Tree: catalog->database->table
> # 2. A time series database is designed. Schema information is stored in
> the traditional Mysql database. Therefore, methods such as
> Schema.getSubSchemaNames() Schema.getSubSchemaMap() will be frequently
> called when executing SQL, especially in the validate phase.
> # Query a SQL sample as follows:
> select * from `catalog`.`database`.`xxtable` limit 10
> # Modified part of the code and connected to the opentracing system
> (jaeger)
> # DEBUG tracks and analyzes the entire execution process of SQL to
> analyze why it is slow, so as to optimize our system
>
> Here is one of our SQL executions:
>
> !Screenshot from 2022-06-10 11-18-54.png!
>
>
>
> Apparently, ICUserCatalogSchema.getSubSchemaMap() is called many times and
> it increases with the number of databases
> The debug code finds that the prepareSql stage will call the
> gatherLattices method, and gatherLattices will access all Schema
> information, which corresponds to databases
>
>
> {code:java}
> private static void gatherLattices(CalciteSchema schema,
> List list) {
> list.addAll(schema.getLatticeMap().values());
> for (CalciteSchema subSchema : schema.getSubSchemaMap().values()) {
> gatherLattices(subSchema, list);
> }
> } {code}
> My question is, why do you care about other database information when
> querying a table, and are there any suggestions for improvement here...
>
>
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.7#820007)
>
[jira] [Created] (CALCITE-5188) Review (and improve?) hints
Ruben Q L created CALCITE-5188:
--
Summary: Review (and improve?) hints
Key: CALCITE-5188
URL: https://issues.apache.org/jira/browse/CALCITE-5188
Project: Calcite
Issue Type: Task
Reporter: Ruben Q L
Hints were initially implemented via CALCITE-482, and later enlarged via
CALCITE-5107 (which included more RelNodes as "hintable").
However, the latter caused some issues, because certain transformations
(RelDecorrelator, RelFieldTrimmer, RelStructuredTypeFlattener) were missing the
hint propagation for the "new" hintables, see details in CALCITE-5177.
The purpose of the current ticket is:
- Review the hint copy/propagation mechanism, see if it can be more robust to
avoid issues like CALCITE-5177 in the future.
- Review some hint-related features, and verify they are still relevant /
correct after CALCITE-5107's implementation, e.g.:
-- {{RelOptUtils#propagateRelHints}} does not propagate hints if visiting depth
is over than 3 (see its javadoc, and {{SubTreeHintPropagateShuttle#visit}}, is
this still correct after CALCITE-5107?
-- {{ResetHintsShuttle}} javadoc mentions "rules" for the "old" hintables
(Project, Aggregate, Join, TableScan); but not for the "new" hintables added in
CALCITE-5107.
-- Other?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
