The command SET GLOBAL PERSISTENT statement_timeout = '2m'; sets the statement timeout for all new sessions to 2 minutes.
Is this the correct way, as I’m getting statements running longer than this?
In theory, this is still possible because some statements are not interrupted, such as the execution of a slow scalar or the creation of a snapshot. If you have an example we might be able to identify the reason.
Oh, and we’re using CrateDB in the cloud, so we don’t have access to command line settings, etc.
We can always set this up for you. Additionally, you can change the default with SET GLOBAL as you mentioned, or provide a session setting during connection or within a session with SET statement_timeout = '2m';.
As we’re using cURL types calls, does this mean on a per session basis, we prepend the string SET GLOBAL PERSISTENT statement_timeout = '2m';
before the select statements ?
e.g.
SET GLOBAL PERSISTENT statement_timeout = ‘2m’; SELECT uuid,ts … "
(We’re only need this for queries)
As we’re using cURL types calls, does this mean on a per session basis, we prepend the string SET GLOBAL PERSISTENT statement_timeout = '2m';
before the select statements ?
To adjust the statement_timeout just for a single session, you would use SET statement_timeout = '2m' without the GLOBAL PERSISTENT.
However currently, sessions in CrateDB using the HTTP endpoint are tied to the TCP session, and the HTTP endpoint only supports single-statement SQL queries. This means that to run multiple queries one needs to issue multiple POST requests within the same TCP session or you need to use a pgwire protocol client/driver. However, with the release of CrateDB 5.9, we will introduce the ability to set session defaults at the user level.