mirror of
https://github.com/hasura/graphql-engine.git
synced 2024-09-11 10:46:25 +03:00
docs: Document support for prepared statements
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:
parent
cc2aa655c7
commit
fdcd4748a6
@ -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 |
|
||||
|
@ -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`.
|
||||
|
||||
:::
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user