โ07-11-2024 05:11 AM - edited โ07-11-2024 05:41 AM
I am running a very simple SQL script within a notebook, using an X-Small SQL Serverless warehouse (that is already running). The execution time is different depending on how it's run:
4s if run interactively (and through SQL editor)
26s if run within a workflow as a notebook task
If you look at the query history screenshot below you see the individual queries are taking the same amount of time to execute, but for some reason there's a few seconds delay between end of one query and start of the next query (line) when running through workflow vs interactively (both using SQL serverless warehouse). I tried both current and preview channel and they both behave the same way
I even tried using an all purpose compute cluster (Single node: Standard_DS3_v2 ยท DBR: 15.3) and the times were consistent when running in a workflow vs interactively.
Script
declare or replace start_time timestamp = current_timestamp();
declare or replace end_time timestamp = current_timestamp();
declare or replace v STRUCT<SOURCE_TBL_MAX_TIMESTAMP STRING, TARGET_TBL_MAX_TIMESTAMP STRING, SOURCE_MAX_TIMESTAMP TIMESTAMP, TARGET_MAX_TIMESTAMP TIMESTAMP, MIN_TIME TIMESTAMP, MAX_TIME TIMESTAMP, MAX_INTERVAL_TIME TIMESTAMP, TABLE_SOURCE STRING, TABLE_TARGET STRING, MERGE_STATEMENT STRING, INTERVAL_COLUMN_NAME STRING, STAGING_TABLE_NAME STRING, STAGING_TABLE_CREATE_STATEMENT STRING, FULL_STAGING_TABLE_NAME STRING>;
select current_timestamp();
select v;
select current_timestamp();
select timestampdiff(MILLISECOND , start_time, current_timestamp()) as total_time_elapsed_ms;
Screenshots
Query History
Further tests
Using a SQL file workflow task, running on X-Small SQL serverless, the same script executes as expected (faster than notebook task):
Not sure why the type of workflow task would impact the execution of the SQL script on a serverless warehouse.
โ07-11-2024 05:17 AM
@SergeRielau - is this another bug or?
โ07-11-2024 11:08 AM
@iamgoda No idea. In DBSQL session variables and their values must be preserved outside the runtime engine (since the session may be migrated), but that doesn't seem to be at play here (and it should not have such an impact).
โ07-11-2024 11:36 AM
Yes and the fact that running it as a SQL script task works. Running it as a notebook task on a SQL serverless instance seems to be the issue.
โ07-12-2024 01:41 AM
@iamgoda we are going to look into how to make this faster. There's a poll loop in Databricks Workflows for SQL notebooks (but not for SQL scripts) which causes things to slow down.
โ07-12-2024 04:43 AM
@BilalAslamDbrx thanks for looking into this and confirming the issue. This doesn't happen if the SQL notebook task is run using all purpose compute in a workflow, so wondering if the poll loop only applies to SQL serverless compute?
โ07-12-2024 07:45 AM
This adds up. This particular polling inefficiency only applies to the flow of notebooks running on warehouses (not on clusters).
โ07-19-2024 04:35 AM
Any idea of whether this will be addressed and when?
โ07-20-2024 08:16 AM
No not yet
โ10-13-2024 01:56 PM
Hello. Are there updates for this issue?
โ10-16-2024 06:39 AM
I was told that it would be fixed in Q4 this year. I am checking for an update again and will let you know if they give me a more exact date.
3 weeks ago
So I was told that the Q4 date was incorrect - in fact there is currently no ETA for when this issue will be fixed. It's considered lower priority by Databricks as not enough customers are impacted or have raised this type of an issue. I would recommend @Ememel that you try and raise this issue through your Databricks support team or Microsoft so it increases the priority?
Join a Regional User Group to connect with local Databricks users. Events will be happening in your city, and you wonโt want to miss the chance to attend and share knowledge.
If there isnโt a group near you, start one and help create a community that brings people together.
Request a New Group