hasura/graphql-engine
1
0
Fork 0
mirror of https://github.com/hasura/graphql-engine.git synced 2024-09-11 10:46:25 +03:00
Code Issues Projects Releases Wiki Activity

docs: Document support for prepared statements

Browse Source 
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9741
Co-authored-by: Sean Park-Ross <94021366+seanparkross@users.noreply.github.com>
GitOrigin-RevId: 2fea0a00ec39d75dbbffb16c3fefae7dba57e815
This commit is contained in:
Philip Lykke Carlsen 2023-07-05 12:49:40 +02:00 committed by hasura-bot
parent cc2aa655c7
commit fdcd4748a6
5 changed files with 27 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
docs/docs/api-reference/syntax-defs.mdx
View File

@ -125,6 +125,25 @@ keywords:
| isolation_level | false | `read-committed` \| `repeatable-read` \| `serializable` | The transaction isolation level in which the queries made to the source will be run with (default: `read-committed`). |
| ssl_configuration | false | [PGCertSettings](#pgcertsettings) | The client SSL certificate settings for the database (_Only available in Cloud_). |
:::info Note
When `use_prepared_statements` is `true`, all SQL queries compiled from GraphQL queries will be
[prepared](https://www.postgresql.org/docs/current/sql-prepare.html) before being executed, meaning that the
database server will cache queries and query plans.
This can result in an improvement in performance when serving mostly complex queries with little variation. But it's
a trade-off that increases memory usage, and under other circumstances the result is not a net performance gain.
And because the prepared statements cache is local to each database connection, the connection pool parameters also
influence its efficiency.
The only way to reasonably know if enabling prepared statements will increase the performance of a Hasura GraphQL
Engine instance is to benchmark it under a representative query load.
This option interacts with the [Query Tags](/observability/cloud-monitoring/query-tags.mdx) feature (see for details),
and the two generally shouldn't be enabled at the same time.
:::
## MsSQLSourceConnectionInfo {#mssqlsourceconnectioninfo}
| Key | Required | Schema | Description |

8
docs/docs/observability/cloud-monitoring/query-tags.mdx
View File

@ -114,10 +114,12 @@ In the above Metadata spec:
4. To add the `request_id` part of the query tags for any source, set the value of <em>omit_request_id</em> field to
<em>false</em>.
:::info
:::info Compatibility with prepared statements
When the `use_prepared_statements` flag for a Postgres source is enabled, omitting the `request_id` part of the query
tags is recommended.
The `use_prepared_statements` flag supported by Postgres sources is largely incompatible with query tags. With query
tags enabled, two otherwise identical GraphQL queries may produce different SQL text, which negates the caching benefit
of prepared statements. If both query tags and `use_prepared_statements` are enabled at the same time, the
`omit_request_id` should be set to `true`.
:::

2
docs/docs/schema/bigquery/logical-models/native-queries.mdx
View File

@ -464,7 +464,7 @@ You can use any SQL that you could potentially use in a parameterized query, wit
The query can take arguments, which are specified in the metadata. These arguments can be used in the SQL using the
syntax `{{argument_name}}`. This syntax resembles popular string templating languages such as Mustache, but does not use
string interpolation. Instead, it works in exactly the same way as prepared statements in the database, and so arguments
string interpolation. Instead, it works in exactly the same way as parameterized queries in the database, and so arguments
do not need escaping or quoting in the SQL itself. They will be treated as variables of the correct type.
This does mean that arguments cannot be used for elements of the SQL that deal with structure. For example, you cannot

2
docs/docs/schema/ms-sql-server/logical-models/native-queries.mdx
View File

@ -467,7 +467,7 @@ You can use any SQL that you could potentially use in a parameterized query, wit
The query can take arguments, which are specified in the metadata. These arguments can be used in the SQL using the
syntax `{{argument_name}}`. This syntax resembles popular string templating languages such as Mustache, but does not use
string interpolation. Instead, it works in exactly the same way as prepared statements in the database, and so arguments
string interpolation. Instead, it works in exactly the same way as parameterized queries in the database, and so arguments
do not need escaping or quoting in the SQL itself. They will be treated as variables of the correct type.
This does mean that arguments cannot be used for elements of the SQL that deal with structure. For example, you cannot

2
docs/docs/schema/postgres/logical-models/native-queries.mdx
View File

@ -463,7 +463,7 @@ You can use any SQL that you could potentially use in a parameterized query, wit
The query can take arguments, which are specified in the metadata. These arguments can be used in the SQL using the
syntax `{{argument_name}}`. This syntax resembles popular string templating languages such as Mustache, but **does not
use string interpolation**. Instead, it works in exactly the same way as prepared statements in the database, and so
use string interpolation**. Instead, it works in exactly the same way as parameterized queries in the database, and so
arguments do not need escaping or quoting in the SQL itself. They will be treated as variables of the correct type.
This does mean that arguments cannot be used for elements of the SQL that deal with structure. For example, you cannot