We have some queries that are hundreds or thousands of lines long that create a QUERY_TEXT_TOO_LARGE error. Is there a query I can run to show the maximum query text length in Trino/hdfs? I couldn't find it here: https://trino.io/docs/current/admin/properties-query-management.html or by doing a search: https://trino.io/docs/current/search.html?q=maximum# I don't have direct access to the server this runs on, but I can run queries on it.

I just created a new user dataengineer and user group data-engineer When I try to connect with the user dataengineer using dbeaver I get the following errors. SQL Error : Query failed (#20210927_124120_00084_kcmzr): Access Denied: Cannot select from table system.jdbc.tables Query failed (#20210927_124120_00084_kcmzr): Access Denied: Cannot select from table system.jdbc.tables Query failed (#20210927_124120_00084_kcmzr): Access Denied: Cannot select from table system.jdbc.tables io.trino.spi.security.AccessDeniedException: Access Denied: Cannot select from table system.jdbc.tables Access Denied: Cannot select from table system.jdbc.tables When I try to connect using the same user from the trino cli I get the following errors trino:jdbc> select 1; _col0 ------- 1 (1 row) Query 20210927_143506_00011_m9sds, FINISHED, 1 node https://trino.afsouth1ctcld.net/ui/query.html?20210927_143506_00011_m9sds Splits: 1 total, 1 done (100,00%) CPU Time: 0,0s total, 0 rows/s, 0B/s, 0% active Per Node: 0,0 parallelism, 0 rows/s, 0B/s Parallelism: 0,0 Peak Memory: 0B 0,34 [0 rows, 0B] [0 rows/s, 0B/s] trino:jdbc> select * from system.jdbc.tables limit 10; Query 20210927_144444_00018_m9sds failed: Access Denied: Cannot select from table system.jdbc.tables io.trino.spi.security.AccessDeniedException: Access Denied: Cannot select from table system.jdbc.tables So the user can connect to trino but not query the system tables. If I connect with a different user called data science it works without any issues. This is what my group.txt and rules.json file looks like group.txt: |- data-science:datascience data-engineer:dataengineer rules.json: |- { "catalogs": [ { "user": "dpadmin", "allow": "all" }, { "group": "data-engineering|data-platform-admin", "catalog": ".*", "allow": "all" }, { "group": "data-science", "catalog": "(iceberg)", "allow": "all" }, { "group": "data-science", "catalog": ".*", "allow": "read-only" }, { "catalog": "system", "allow": "none" } ], "schemas": [ { "user": "dpadmin", "schema": ".*", "owner": true }, { "group": "data-engineering", "schema": ".*", "owner": true }, { "group": "data-science", "catalog": ".*", "schema": ".*", "owner": false }, { "user": "guest", "owner": false } ], "tables": [ { "group": "data-science", "privileges": ["SELECT", "INSERT", "DELETE", "OWNERSHIP"], "catalog": "(iceberg)", "schema": "(ds_scratch)" }, { "group": "data-science", "privileges": ["SELECT"], "catalog": ".*", "schema": ".*" } ] }

We use Trino (https://trino.io/) to connect to HDFS. I discovered that the data in the information_schema tables, for example: select * from information_schema.columns clz where clz.table_catalog = ‘hive’ and clz.table_schema = ‘’ and clz.table_name = ‘’ doesn’t always match up with what I get if I run show tables from [schema] show columns in [schema].[table] etc. It seems that the *show tables*/*show columns* commands pretty much always match up with what I see if I run the hadoop command (hadoop fs -ls ...) to show the contents of the hdfs folder. So I’m trying to figure out: - why the information_schema doesn’t give the same results as show tables/show columns/etc. - if there is a way to refresh/update information_schema to make it current Thank you.

We are thinking of migrating an Oracle RDS database to Athena Trino Datalake. We would keep all database names, schemas, tables, and columns the same. Would SQL that runs correctly against the Oracle RDS database be 100% guaranteed to run correctly against the Athena Trina Datalake (with possible trivial differences, such as sorting-order for queries without ORDER BY)? My guess is that it would not, though hopefully most such SQL would run correctly in both systems.