Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Analyzer: DB::Exception: Received from localhost:9000. DB::Exception: Query tree is too big. #63701

Open
Selfeer opened this issue May 13, 2024 · 5 comments · May be fixed by #64377
Open

Analyzer: DB::Exception: Received from localhost:9000. DB::Exception: Query tree is too big. #63701

Selfeer opened this issue May 13, 2024 · 5 comments · May be fixed by #64377
Assignees
Labels
analyzer Issues and pull-requests related to new analyzer bug Confirmed user-visible misbehaviour in official release

Comments

@Selfeer
Copy link

Selfeer commented May 13, 2024

Starting from ClickHouse 24.3, given that experimental_analyzer is on by default I started to get the following error:

Code: 36. DB::Exception: Received from localhost:9000. DB::Exception: Query tree is too big. Maximum: 500000. (BAD_ARGUMENTS)

I randomly get that error after executing:

SELECT bool, toTypeName(bool) FROM table0_fc3716d7_0be4_11ef_9a0e_31523c49d68a ORDER BY tuple(*) FORMAT JSONEachRow

I executed a lot of queries before that, where I both read from and write to a Parquet file locally.

Given that I never got this error before with the same set of queries, maybe it makes sense to have the experimental_analyzer turned off by default?

@Selfeer Selfeer added the potential bug To be reviewed by developers and confirmed/rejected. label May 13, 2024
@Algunenano Algunenano added the st-need-info We need extra data to continue (waiting for response) label May 13, 2024
@Algunenano
Copy link
Member

I randomly get that error after executing:

Can you check and share system.query_log for the failing queries? Also share the table definition of the tables involved. Ideally a reproducer via https://fiddle.clickhouse.com/ is much better.

maybe it makes sense to have the experimental_analyzer turned off by default?

No. It might have bugs that we are working on fixing, but the analyzer has fixed hundreds of long standing issues in CH.

@Selfeer
Copy link
Author

Selfeer commented May 21, 2024

Hey @Algunenano,

Here are the steps how I was able to reproduce this issue;

  1. Create table_1 with Parquet engine with the following structure: https://gist.github.com/Selfeer/87edac697060fb4850a99a07cd27931b
  2. Insert data into all of the columns in that table
  3. Execute the: cp /var/lib/clickhouse/data/default/table_1/data.Parquet /var/lib/clickhouse/user_files/table_1.Parquet
  4. Create table_2 table with the same structure but the ENGINE = Memory
  5. Insert into the table_2 values from the table_1.Parquet via this command
INSERT INTO table_2 FROM INFILE '/var/lib/clickhouse/user_files/table_1.Parquet' FORMAT Parquet
  1. Try to select data from the newly created table
SELECT bool, toTypeName(bool) FROM table0_6f9f2a27_1770_11ef_a7cc_810020732561 ORDER BY tuple(*) FORMAT JSONEachRow
  1. Get the following exception:
Code: 36. DB::Exception: Received from localhost:9000. DB::Exception: Query tree is too big. Maximum: 500000. (BAD_ARGUMENTS)

@den-crane
Copy link
Contributor

den-crane commented May 21, 2024

It simply related to the number of columns in the tuple function argument

https://fiddle.clickhouse.com/c953f52a-f975-47c5-a038-0de2955d1ec9

It's not a real issue, it just synthetic nonsense.
Real people should use ORDER BY ALL instead of ORDER BY tuple(*)

The same with SELECT tuple(*) FROM t https://fiddle.clickhouse.com/8dd922f5-0fa3-485c-a4bd-339c717f3509

@Selfeer
Copy link
Author

Selfeer commented May 22, 2024

The issue is more that it doesn't throw that error if the analyzer is disabled or if we use the older versions where its off by default.

@novikd novikd self-assigned this May 24, 2024
@novikd novikd added analyzer Issues and pull-requests related to new analyzer and removed st-need-info We need extra data to continue (waiting for response) labels May 24, 2024
@novikd
Copy link
Member

novikd commented May 24, 2024

I confirm there is a bug in the implementation of validateTreeSize function. The tree size for the leaf nodes is not always 1.

if (processed_children)
{
++tree_size;
node_to_tree_size.emplace(node_to_process, tree_size);
continue;
}

I'll fix it. As a temporary workaround you can increase the value of max_expanded_ast_elements setting.

@novikd novikd added bug Confirmed user-visible misbehaviour in official release and removed potential bug To be reviewed by developers and confirmed/rejected. labels May 24, 2024
@novikd novikd linked a pull request May 24, 2024 that will close this issue
30 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer Issues and pull-requests related to new analyzer bug Confirmed user-visible misbehaviour in official release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants