Skip to content

Don't execute queries in background when max_threads is 0#41586

Merged
eileencodes merged 1 commit intorails:mainfrom
eileencodes:dont-initialize-executors-for-configs-that-disable-it
Mar 2, 2021
Merged

Don't execute queries in background when max_threads is 0#41586
eileencodes merged 1 commit intorails:mainfrom
eileencodes:dont-initialize-executors-for-configs-that-disable-it

Conversation

@eileencodes
Copy link
Copy Markdown
Member

In the multi_thread_pool executor it's possible to have a database
configuration that wouldn't work well with a thread exectutor. This
change checks the @db_config.max_threads and if it is not greater than
0 we won't create a thread pool for that configuration. Database
configurations without a proper value set for max_threads will return
a nil async executor and will run queries for those connection pools
in the foreground. This allows applications to more easily control which
database configurations in their app support async queries. In this
setup one database coule be configured to run parallel queries while all
other databases run queries in the foreground.

cc/ @jhawthorn @rafaelfranca @byroot

Copy link
Copy Markdown
Member

@byroot byroot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👌

Copy link
Copy Markdown
Member

@kamipo kamipo Mar 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about adding # :nodoc:?

In other words, is it intended to be exposed in the API doc?

In the multi_thread_pool executor it's possible to have a database
configuration that wouldn't work well with a thread exectutor. This
change checks the `@db_config.max_threads` and if it is not greater than
0 we won't create a thread pool for that configuration. Database
configurations without a proper value set for `max_threads` will return
a `nil` async executor and will run queries for those connection pools
in the foreground. This allows applications to more easily control which
database configurations in their app support async queries. In this
setup one database coule be configured to run parallel queries while all
other databases run queries in the foreground.
@eileencodes eileencodes force-pushed the dont-initialize-executors-for-configs-that-disable-it branch from b6e2775 to 6b9027b Compare March 2, 2021 12:53
@eileencodes eileencodes merged commit c476864 into rails:main Mar 2, 2021
@eileencodes eileencodes deleted the dont-initialize-executors-for-configs-that-disable-it branch March 2, 2021 13:14
abhaynikam added a commit to abhaynikam/rails that referenced this pull request Mar 3, 2021
PR: rails#41586

While reading the change noticed the test cases used assert
for comparsion. The problem here is assert would never raise
error if the expected and actual value do not match.

After changing it to the assert_equal, async_query_executor test
cases started failing because the connection was already established
before the spec was ran and setting global `global_executor_concurrency`
did not reset the global_thread_pool_async_query_executor

Changes to assert_equal also broke the async_query_executor = :multi_thread_pool
specs as the max_length defaults to pool(i.e: 5) in the database configuration.

PR attemps to fix all the above mentioned issues in the asynchronous_queries_test.rb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants