Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Version 2 du moteur Athena
La version 2 du moteur Athena apporte les modifications suivantes.
Améliorations et nouvelles fonctions
-
EXPLAINet EXPLAINANALYZE— Vous pouvez utiliser l'
EXPLAIN
instruction dans Athena pour afficher le plan d'exécution de vos SQL requêtes. PermetEXPLAIN ANALYZE
de visualiser le plan d'exécution distribué pour vos SQL requêtes et le coût de chaque opération. Pour plus d’informations, consultez Utilisation de EXPLAIN et EXPLAIN ANALYZE sur Athena. -
Requêtes fédérées – Les requêtes fédérées sont prises en charge dans la version 2 du moteur Athena. Pour plus d’informations, consultez Utilisation de la requête fédérée d’Amazon Athena.
-
Fonctions géospatiales – Plus de 25 fonctions géospatiales ont été ajoutées. Pour plus d’informations, consultez Nouvelles fonctions géospatiales de la version 2 du moteur Athena.
-
Schéma imbriqué – La prise en charge de la lecture de schémas imbriqués a été ajoutée, réduisant ainsi les coûts.
-
Instructions préparés – Utilisez des instructions préparées pour l'exécution répétée d'une même requête avec des paramètres de requête différents. Une déclaration préparée contient des paramètres fictifs dont vous transmettez les valeurs au moment de l'exécution. Les déclarations préparées aident à prévenir les attaques SQL par injection. Pour plus d’informations, consultez Utilisation de requêtes paramétrées.
-
Prise en charge d'évolution de schéma – La prise en charge de l'évolution du schéma a été ajoutée pour les données au format Parquet.
-
Ajout de la prise en charge de la lecture de colonnes de type tableau, mappage ou ligne à partir de partitions dont le schéma de partition est différent du schéma de table. Cela peut se produire lorsque le schéma de table a été mis à jour après la création de la partition. Les types de colonnes modifiés doivent être compatibles. Pour les types ligne, des champs de fin peuvent être ajoutés ou supprimés, mais les champs correspondants (par ordre ordinal) doivent avoir le même nom.
-
ORCles fichiers peuvent désormais avoir des colonnes de structure avec des champs manquants. Cela permet de modifier le schéma de la table sans réécrire les ORC fichiers.
-
ORCles colonnes de structure sont désormais mappées par nom plutôt que par ordinal. Cela gère correctement les champs de structure manquants ou supplémentaires dans le ORC fichier.
-
-
SQLOFFSET— La SQL
OFFSET
clause est désormais soutenue dans lesSELECT
déclarations. Pour plus d’informations, consultez SELECT. -
UNLOADinstruction — Vous pouvez utiliser l'
UNLOAD
instruction pour écrire le résultat d'uneSELECT
requête aux JSON formats PARQUET ORCAVRO,, et. Pour plus d’informations, consultez UNLOAD.
Amélioration des regroupements, des jointures et des sous-requêtes
-
Regroupement complexe – Ajout de la prise en charge des opérations de regroupement complexes.
-
Sous-requêtes corrélées – Ajout de la prise en charge des sous-requêtes corrélées dans les prédicats
IN
et des sous-requêtes corrélées nécessitant des forçages de type. -
CROSSJOIN— Ajout du support pour
CROSS JOIN
les tablesLATERAL
dérivées. -
GROUPINGSETS— Ajout de la prise en charge des
ORDER BY
clauses dans les agrégations pour les requêtes qui utilisentGROUPING SETS
. -
Expressions Lambda – Ajout de la prise en charge du déréférencement des champs de ligne dans les expressions Lambda.
-
Valeurs nulles dans les semi-jointures – Ajout de la prise en charge des valeurs nulles sur le côté gauche d'une semi-jointure (c'est-à-dire un prédicat
IN
avec des sous-requêtes). -
Jointures spatiales – Ajout de la prise en charge des jointures spatiales de diffusion et des jointures spatiales gauches.
-
Déversement sur le disque – Pour les opérations
INNER JOIN
etLEFT JOIN
à nécessitant beaucoup de mémoire, Athena décharge les résultats des opérations intermédiaires sur le disque. Cela permet l'exécution de requêtes nécessitant de grandes quantités de mémoire.
Amélioration des types de données
-
INTfor INTEGER — Ajout du support pour
INT
en tant qu'alias pour le type deINTEGER
données. -
INTERVALtypes — Ajout du support pour le casting en
INTERVAL
types. -
IPADDRESS— Ajout d'un nouveau
IPADDRESS
type pour représenter les adresses IP dans les DML requêtes. Ajout de la prise en charge de la conversion entre le typeVARBINARY
et le typeIPADDRESS
. LeIPADDRESS
type n'est pas reconnu dans les DDL requêtes. -
IS DISTINCT FROM — Ajout du
IS DISTINCT FROM
support pour lesIPADDRESS
typesJSON
et. -
Contrôles d'égalité des nuls – Les contrôles d'égalité pour les valeurs nulles dans les structures de données
ARRAY
,MAP
etROW
sont désormais pris en charge. Par exemple, l'expressionARRAY ['1', '3', null] = ARRAY ['1', '2', null]
renvoiefalse
. Auparavant, un élément nul renvoyait le message d'erreurcomparison not supported
(comparaison non prise en charge). -
Forçage de type de rangée – La forçage entre les types de lignes sans tenir compte des noms de champs est maintenant autorisée. Auparavant, un type de ligne était forçable avec un autre type de ligne uniquement si le nom du champ dans le type source correspondait au type cible, ou si le type cible avait un nom de champ anonyme.
-
Soustraction temporelle – Mise en œuvre de la soustraction pour tous les types
TIME
etTIMESTAMP
. -
Unicode – Ajout de la prise en charge des séquences Unicode échappées dans les libellés chaînes.
-
VARBINARYconcaténation — Ajout du support pour la concaténation de valeurs.
VARBINARY
Fonctions de fenêtrage – Les fonctions de valeur de fenêtre prennent désormais en charge
IGNORE NULLS
etRESPECT NULLS
.
Types d'entrée supplémentaires pour les fonctions
Les fonctions suivantes acceptent désormais des types d'entrée supplémentaires. Pour plus d'informations sur chaque fonction, consultez le lien correspondant à la documentation Presto.
-
approx_distinct() – La fonction approx_distinct ()
prend désormais en charge les types suivants : INTEGER
,SMALLINT
,TINYINT
,DECIMAL
,REAL
,DATE
,TIMESTAMP
,TIMESTAMP WITH TIME ZONE
,TIME
,TIME WITH TIME ZONE
,IPADDRESS
etCHAR
. -
Avg(), sum() – Les fonctions d'agrégation avg()
et sum() prennent désormais en charge le type de données INTERVAL
. -
Lpad(), rpad() – Les fonctions lpad
et rpad fonctionnent maintenant sur les entrées VARBINARY
. -
Min(), max() – Les fonctions d'agrégation min()
and max() autorisent désormais les types d'entrée inconnus au moment de l'analyse de la requête afin que vous puissiez utiliser les fonctions avec des libellés NULL
. -
regexp_replace() – Ajout d'une variante de la fonction regexp_replace()
qui peut exécuter une fonction Lambda pour chaque remplacement. -
Sequence() – Ajout de variantes
DATE
pour la fonction sequence(), y compris une variante avec un incrément implicite d'un jour. -
ST_Area() – La fonction géospatiale ST_Area()
prend désormais en charge tous les types de géométrie. -
Substr() – La fonction substr
fonctionne désormais sur les entrées VARBINARY
. -
zip_with() – Les tableaux dont la longueur n'est pas adaptée peuvent maintenant être utilisés avec zip_with()
. Les positions manquantes sont remplies avec le caractère nul. Auparavant, une erreur était générée lorsque des tableaux de longueurs différentes étaient transmis. Cette modification peut rendre difficile la distinction entre les valeurs qui étaient nulles à l'origine et celles qui ont été ajoutées pour compléter les tableaux à la même longueur.
Fonctions ajoutées
La liste suivante contient les fonctions qui sont nouvelles à partir de la version 2 du moteur Athena. La liste n'inclut pas les fonctions géospatiales. Pour une liste des fonctions géospatiales, voir Nouvelles fonctions géospatiales de la version 2 du moteur Athena.
Pour plus d'informations sur chaque fonction, consultez le lien correspondant à la documentation Presto.
Fonctions d’agrégation
Opérateurs et fonctions de tableau
array_sort()
Fonctions et opérateurs binaires
Date and Time Functions and Operators
Mappage des fonctions et des opérateurs
Fonctions et opérateurs mathématiques
Fonctions de prétraitement quantile
Ajout des fonctions de prétraitement quantileqdigest
.
Fonctions et opérateurs de chaîne
Améliorations des performances
Les performances des fonctions suivantes ont été améliorées dans la version 2 du moteur Athena.
Les performances des requêtes
-
Performance de jointure de diffusion – Amélioration des performances de jointure de diffusion en appliquant une taille dynamique de partition dans le composant master.
-
Tables compartimentées – Amélioration des performances pour l'écriture dans des tables compartimentées lorsque les données écrites sont déjà partitionnées de manière appropriée (par exemple, lorsque la sortie provient d'une jointure compartimentée).
-
DISTINCT— Performances améliorées pour certaines requêtes utilisant
DISTINCT
.Filtrage dynamique et élagage des partitions – Ces améliorations permettent d'augmenter les performances et de réduire la quantité de données analysées dans les requêtes.
-
Opérations de filtrage et projection – Les opérations de filtrage et de projection sont désormais toujours traitées par des colonnes si possible. Le moteur tire automatiquement parti des codages de dictionnaire lorsqu'ils sont efficaces.
-
Regroupement des échanges – Amélioration des performances pour les requêtes avec regroupement des échanges.
-
Agrégations globales – Amélioration des performances pour certaines requêtes qui effectuent des agrégations globales filtrées.
-
GROUPINGSETS,CUBE, ROLLUP — Performances améliorées pour les requêtes impliquant
CUBE
ouGROUPING SETS
ROLLUP
, que vous pouvez utiliser pour agréger plusieurs ensembles de colonnes en une seule requête. -
Filtres hautement sélectifs – Amélioration des performances des requêtes avec des filtres hautement sélectifs.
-
JOINet AGGREGATE opérations — Les performances
JOIN
et lesAGGREGATE
opérations ont été améliorées. -
LIKE— Amélioration des performances des requêtes qui utilisent des
LIKE
prédicats sur les colonnes desinformation_schema
tables. -
ORDERBY et LIMIT — Plans, performances et utilisation de la mémoire améliorés pour les requêtes impliquant
ORDER BY
etLIMIT
afin d'éviter des échanges de données inutiles. -
ORDERBY : les
ORDER BY
opérations sont désormais distribuées par défaut, ce qui permet d'utiliserORDER BY
des clauses plus volumineuses. -
ROWconversions de types : performances améliorées lors de la conversion entre
ROW
types. -
Types structurels – Amélioration des performances des requêtes qui traitent des types structurels et qui contiennent des balayages, des jointures, des agrégations ou des écritures de table.
-
Analyse de table – Une règle d'optimisation a été introduite pour éviter les analyses de tables en double dans certains cas.
-
UNION— Performances améliorées pour les
UNION
requêtes.
Performances de planification des requêtes
-
Performances de planification – Amélioration des performances de planification des requêtes qui joignent plusieurs tables avec un grand nombre de colonnes.
-
Évaluations des prédicats – Amélioration des performances d'évaluation des prédicats lors du refoulement des prédicats dans la planification.
-
Support du pushdown du prédicat pour le casting — Support du pushdown du prédicat pour le
<column>
IN
<values list>
prédicat où les valeurs de la liste de valeurs doivent être tranchées pour correspondre au type de colonne. -
Inférence de prédicat et pushdown : inférence de prédicat et pushdown étendus pour les requêtes utilisant un
<symbol>
IN
<subquery>
prédicat. -
Délais – Correction d'un bug qui pouvait, dans de rares cas, entraîner des délais d'expiration de la planification des requêtes.
Performances de jointure
-
Jointures avec des colonnes mappées – Amélioration des performances des jointures et des agrégations qui incluent des colonnes mappées.
-
Jointures avec uniquement des conditions de non-égalité – Amélioration des performances des jointures avec uniquement des conditions de non-égalité en utilisant une jointure par boucle imbriquée au lieu d'une jointure par hachage.
-
Jointures externes – Le type de distribution de jointure est désormais automatiquement sélectionné pour les requêtes impliquant des jointures externes.
-
Jointure de plage sur une fonction – Amélioration des performances des jointures lorsque la condition est une plage sur une fonction (par exemple,
a JOIN b ON b.x < f(a.x) AND b.x > g(a.x)
). -
S pill-to-disk — Correction de bogues et de problèmes de mémoire spill-to-disk connexes afin d'améliorer les performances et de réduire les erreurs de mémoire lors
JOIN
des opérations.
Performances des sous-requêtes
-
EXISTSSous-requêtes corrélées : amélioration des performances des sous-requêtes corrélées
EXISTS
. -
Sous-requêtes corrélées avec des égalités – Amélioration de la prise en charge des sous-requêtes corrélées contenant des prédicats d'égalité.
-
Sous-requêtes corrélées avec des inégalités – Amélioration des performances des sous-requêtes corrélées qui contiennent des inégalités.
-
Agrégations Count(*) sur les sous-requêtes – Amélioration des performances des agrégations
count(*)
sur des sous-requêtes avec une cardinalité constante connue. -
Propagation du filtre de requête externe – Amélioration des performances des sous-requêtes corrélées lorsque les filtres de la requête externe peuvent être propagés à la sous-requête.
Performance des fonctions
-
Fonctions de fenêtrage d'agrégation – Amélioration des performances des fonctions de fenêtrage d'agrégation.
-
element_at() – Amélioration des performances de
element_at()
pour les mappages afin que le temps soit constant plutôt que proportionnel à la taille du mappage. -
Grouping() – Amélioration des performances des requêtes impliquant
grouping()
. -
JSONcasting — Amélioration des performances du casting de
MAP
typesJSON
àARRAY
ou. -
Fonctions de retour de mappage – Amélioration des performances des fonctions de retour de mappage.
-
ap-to-map Casting M — Amélioration des performances du map-to-map casting.
-
Min() et max() – Les fonctions
min()
etmax()
ont été optimisées pour éviter la création inutile d'objets, réduisant ainsi les coûts du récupérateur de mémoire. -
row_number() – Amélioration des performances et de l'utilisation de la mémoire pour les requêtes utilisant
row_number()
suivi d'un filtre sur les numéros de ligne générés. -
Fonctions de fenêtrage – Amélioration des performances des requêtes contenant des fonctions de fenêtrage avec des clauses
PARTITION BY
etORDER BY
identiques. -
Fonctions de fenêtrage – Amélioration des performances de certaines fonctions de fenêtrage (par exemple,
LAG
) qui ont des spécifications similaires.
Performances géospatiales
-
Sérialisation de la géométrie – Amélioration des performances de sérialisation des valeurs géométriques.
-
Fonctions géospatiales – Amélioration des performances de
ST_Intersects()
,ST_Contains()
,ST_Touches()
,ST_Within()
,ST_Overlaps()
,ST_Disjoint()
,transform_values()
,ST_XMin()
,ST_XMax()
,ST_YMin()
,ST_YMax()
,ST_Crosses()
etarray_intersect()
. -
ST_Distance() – Amélioration des performances des requêtes de jointure impliquant la fonction
ST_Distance()
. -
ST_Intersection() – Optimisation de la fonction
ST_Intersection()
pour les rectangles alignés sur les axes de coordonnées (par exemple, les polygones produits par les fonctionsST_Envelope()
etbing_tile_polygon()
).
JSONaméliorations connexes
Fonctions de mappage
-
Amélioration des performances de l'indice de mappage de
O(n)
àO(1)
dans tous les cas. Auparavant, seules les mappages produits par certaines fonctions et lecteurs ont profité de cette amélioration. -
Ajout des fonctions
map_from_entries()
etmap_entries()
.
Forçage de type
-
Ajout de la possibilité de forçer vers
JSON
à partir deREAL
,TINYINT
ouSMALLINT
. -
Vous pouvez désormais forçer
JSON
versROW
même si le codeJSON
ne contient pas tous les champs de laROW
. -
Amélioration des performances de
CAST(json_parse(...) AS ...)
. -
Amélioration des performances du forçage du type
JSON
au typeARRAY
ouMAP
.
Nouvelles JSON fonctions
Évolutions
Les modifications de type interruption comprennent des corrections de bogues, des modifications des fonctions géospatiales, des fonctions remplacées et l'introduction de limites. Les améliorations apportées à ANSI SQL la conformité peuvent interrompre les requêtes qui dépendent d'un comportement non standard.
Correctifs de bogue
Les modifications suivantes corrigent des problèmes de comportement qui entraînaient l'exécution réussie de requêtes, mais avec des résultats imprécis.
-
Les colonnes de parquet fixed_len_byte_array sont désormais acceptées comme DECIMAL : les requêtes sur les colonnes de type parquet
fixed_len_byte_array
aboutissent et renvoient des valeurs correctes si elles sont annotées comme dans le schéma de parquet.DECIMAL
Les requêtes sur des colonnesfixed_len_byte_array
sans annotationDECIMAL
échouent avec une erreur. Auparavant, les requêtes sur desfixed_len_byte_array
colonnes sans DECIMAL annotation aboutissaient mais renvoyaient des valeurs incompréhensibles. -
json_parse() n'ignore plus les caractère de droite – Auparavant, les entrées telles que
[1,2]abc
étaient analysées avec succès en tant que[1,2]
. L'utilisation de caractères de fin produit désormais le message d'erreurImpossible de convertir '[1, 2] abc' en. JSON
-
Correction de la précision décimale arrondie () : arrondit
round(x, d)
désormais correctementx
quandx
est a DECIMAL ou quandx
est a DECIMAL avec une échelle de 0 etd
est un entier négatif. Auparavant, aucun arrondissement n'était effectué dans ces cas. -
round(x, d) et truncate(x, d) – Le paramètre
d
dans la signature des fonctionsround(x, d)
ettruncate(x, d)
est maintenant de typeINTEGER
. Précédemment,d
pourrait être de typeBIGINT
. -
Map() avec des clés dupliquées –
map()
déclenche désormais une erreur en cas de clés dupliquées au lieu de produire silencieusement un mappage corrompu. Les requêtes qui construisent actuellement des valeurs de mappage en utilisant des clés dupliquées échouent désormais avec une erreur. -
map_from_entries() déclenche une erreur avec des entrées nulles –
map_from_entries()
déclenche désormais une erreur lorsque le tableau d'entrée contient une entrée nulle. Requêtes qui construisent un mappage en passantNULL
comme une valeur échouent maintenant. -
Tables – Les tables qui ont des types de partition non pris en charge ne peuvent plus être créées.
-
Amélioration de la stabilité numérique des fonctions statistiques – La stabilité numérique des fonctions statistiques
corr()
,covar_samp()
,regr_intercept()
etregr_slope()
a été améliorée. -
TIMESTAMPla précision définie dans le parquet est désormais respectée — La précision des
TIMESTAMP
valeurs et la précision définie pour laTIMESTAMP
colonne dans le schéma Parquet doivent désormais correspondre. Les précisions non correspondantes entraînent des horodatages incorrects. -
Informations de fuseau horaire — Les informations de fuseau horaire sont désormais calculées à l'aide du package java.time
de Java 1.8. SDK -
SUMdes MONTH types de données INTERVAL _ DAY _TO_ SECOND et INTERVAL _ YEAR _TO_ — Vous ne pouvez plus les utiliser directement.
SUM(NULL)
Pour utiliserSUM(NULL)
, forcezNULL
vers un type de données commeBIGINT
,DECIMAL
,REAL
,DOUBLE
,INTERVAL_DAY_TO_SECOND
ouINTERVAL_YEAR_TO_MONTH
.
Modifications apportées aux fonctions géospatiales
Les modifications apportées aux fonctions géospatiales sont les suivantes.
-
Modifications des noms des fonctions – Certains noms de fonctions ont changé. Pour plus d’informations, consultez Modifications des noms des fonctions géospatiales dans la version 2 du moteur Athena.
-
VARBINARYinput — Le
VARBINARY
type n'est plus directement pris en charge pour l'entrée dans les fonctions géospatiales. Par exemple, pour calculer directement la surface d'une géométrie, celle-ci doit maintenant être saisie au formatVARCHAR
ouGEOMETRY
. La solution de contournement consiste à utiliser les fonctions de transformation, comme dans les exemples suivants.-
À utiliser
ST_area()
pour calculer la zoneVARBINARY
d'entrée au format Known Binary (WKB), transmettez d'ST_GeomFromBinary()
abord l'entrée à, par exemple :ST_area(ST_GeomFromBinary(
<wkb_varbinary_value>
)) -
Pour utiliser
ST_area()
afin de calculer la zone pour une entréeVARBINARY
au format binaire hérité, passez d'abord l'entrée à la fonctionST_GeomFromLegacyBinary()
, par exemple :ST_area(ST_GeomFromLegacyBinary(
<legacy_varbinary_value>
))
-
-
ST_ ExteriorRing () et ST_Polygon () — ST_ExteriorRing()et n'acceptent ST_Polygon()désormais que les polygones en entrée. Auparavant, ces fonctions acceptaient par erreur d'autres géométries.
-
ST_Distance () — Comme l'exige la spécification SQL /MM
, la ST_Distance()fonction renvoie désormais NULL
si l'une des entrées est une géométrie vide. Auparavant,NaN
était renvoyé.
ANSISQLconformité
Les problèmes de syntaxe et de comportement suivants ont été corrigés conformément à la ANSI SQL norme.
-
Opérations Cast () — Les opérations Cast () sont actuellement REAL ou DOUBLE DECIMAL seront désormais conformes à la SQL norme. Par exemple,
cast (double '100000000000000000000000000000000' as decimal(38))
retournait auparavant100000000000000005366162204393472
, mais retourne maintenant100000000000000000000000000000000
. -
JOIN... USING—
JOIN ... USING
est désormais conforme à la SQL sémantique standard. Auparavant,JOIN ... USING
nécessitait de qualifier le nom de la table en colonnes, et la colonne des deux tables était présente dans le résultat. Les qualifications de la table sont maintenant invalides et la colonne n'est présente qu'une seule fois dans le résultat. -
ROWlittéraux de type supprimés — Le format de ROW type littéral n'
ROW<int, int>(1, 2)
est plus pris en charge. Utilisez la syntaxeROW(1 int, 2 int)
à la place. -
Sémantique d'agrégation groupée – Les agrégations groupées utilisent la sémantique
IS NOT DISTINCT FROM
plutôt que sémantique d'égalité. LLes agrégations groupées renvoient désormais des résultats corrects et présentent des performances améliorées lors du regroupement sur des valeurs à virgule flottanteNaN
. Le regroupement sur les types de mappage, de liste et de ligne qui contiennent des valeurs nulles est pris en charge. -
Les types entre guillemets ne sont plus autorisés : conformément à la ANSI SQL norme, les types de données ne peuvent plus être placés entre guillemets. Par exemple,
SELECT "date" '2020-02-02'
n'est plus une requête valide. À la place, utilisez la syntaxeSELECT date '2020-02-02'
. -
Accès aux champs de ligne anonymes – Les champs de ligne anonymes ne sont plus accessibles à l'aide de la syntaxe [
.field0, .field1, ...
]. -
Opérations de regroupement complexes – Les opérations de regroupement complexes,
GROUPING SETS
,CUBE
etROLLUP
ne prennent pas en charge le regroupement sur des expressions composées de colonnes d'entrée. Seuls les noms de colonnes sont autorisés.
Fonctions remplacées
Les fonctions suivantes ne sont plus prises en charge et ont été remplacées par une syntaxe qui produit les mêmes résultats.
-
information_schema.__internal_partitions__ – L'utilisation de
__internal_partitions__
n'est plus prise en charge par le moteur Athena version 2. Pour une syntaxe équivalente, utilisezSELECT * FROM "
ou<table_name>
$partitions"SHOW PARTITIONS
. Pour plus d’informations, consultez Liste des partitions d'une table spécifique. -
Fonctions géospatiales remplacées – Pour une liste des fonctions géospatiales dont les noms ont changé, voirModifications des noms des fonctions géospatiales dans la version 2 du moteur Athena.
Limites
Les limites suivantes ont été introduites dans la version 2 du moteur Athena afin de s'assurer que les requêtes n'échouent pas en raison de limitations de ressources. Ces limites ne sont pas configurables par les utilisateurs.
-
Nombre d'éléments de résultat – Le nombre d'éléments de résultat
n
est limité à 10 000 ou moins pour les fonctions suivantes :min(col, n)
,max(col, n)
,min_by(col1, col2, n)
etmax_by(col1, col2, n)
. -
GROUPINGSETS— Le nombre maximum de tranches dans un ensemble de regroupement est de 2 048.
-
Longueur maximale de la ligne du fichier texte : la longueur de ligne maximale par défaut pour les fichiers texte est de 200 Mo.
-
Taille maximale des résultats de la fonction de séquence – La taille maximale de résultat d'une fonction de séquence est de 50 000 entrées. Par exemple,
SELECT sequence(0,45000,1)
réussit, maisSELECT sequence(0,55000,1)
échoue avec le message d'erreurLe résultat de la fonction de séquence ne doit pas comporter plus de 50 000 entrées
. Cette limite s'applique à tous les types d'entrées pour les fonctions de séquence, y compris aux horodatages.