what are such queries for? is it to check if a table still exists or deleted?
SELECT TRUE AS "_" FROM "schema"."table" WHERE 1 <> 1 LIMIT 0
what are such queries for? is it to check if a table still exists or deleted?
SELECT TRUE AS "_" FROM "schema"."table" WHERE 1 <> 1 LIMIT 0
that's Metabase trying to guess if it has access to the tables or not
Is there any way to stop these? Somehow these are getting stuck in our Redshift DWH and blocking other important queries, impacting the end-user experience.
If can't be stopped then at least can there be better control over when these get triggered?
There are queries that get triggered for field values which also block other queries if the scanned table is large.
I think, at least the admin should have complete control over all such qeries.
Redshift allows you to build queues in order to provide some queries priority over others. I would suggest you do that and also go to settings->admin->databases and select "choose when sync and scan happens"
All of that is already done, we're still facing issues. And when we check, such queries are there for a long time.
We have disabled all types of scans for now. And we're also using Redshift auto-WLM w/Metabase queries as one queue with the highest priority. All other queries go to the default queue.
On the complete opposite, those queries should be the lowest priority so they don’t slow down the analytical queries.
If you have already tuned the sync settings then it’s time to go to the table metadata section and switch the type of filter that a field has. Go to every single field and switch from “a list of all values” to “input box”
Yes, have done that as well to stop field filter value scan queries but as you mentioned these queries are for checking if Metabase has table access or not. Not sure what to do about these.
Also, how can we exclude Metabase system queries from the Metabase queue? We've one Redshift user for Metabase, and that includes all the queries triggered via Metabase (by analyst, dashboard open or system).
You should have one user for Metabase only, not share the same user.
About other queries (e.g. checking for access) you can’t disable them unless you want to disable the entire sync and scan system
Fair enough, makes sense. These will trigger if we wanna show available schemas & tables in the UI.
Yes, we've one user for all Metabase queries, and all the other queries to Redshift go to a separate queue.
Thanks for the quick responses!