Indique le nom de la base à tester. Si elle n'est pas spécifier, la variable d'environnement PGDATABASE est utilisée. Si elle n'est pas configurée, le nom d'utilisateur indiqué pour la connexion est utilisé.

Nécessaire pour passer en mode initialisation.

N'effectue qu'une partie des étapes d'initialisation habituelles. init_steps spécifie les étapes d'initialisation à exécuter, à raison d'un caractère par étape. Chaque étape est appelée dans l'ordre indiqué. La valeur par défaut est dtgvp. Voici la liste des différentes étapes disponibles :

Crée les tables pgbench_accounts, pgbench_tellers et pgbench_branches avec le facteur de remplissage (fillfactor) spécifié. La valeur par défaut est 100.

Ne réalise pas de VACUUM après l'initialisation. (Cette option supprime l'étape d'initialisation v, même si elle était précisée dans -I.)

Passe du mode verbeux au mode silencieux, en n'affichant qu'un message toutes les 5 secondes. Par défaut, on affiche un message toutes les 100 000 lignes, ce qui engendre souvent plusieurs lignes toutes les secondes (particulièrement sur du bon matériel)

Ce paramètre n'a pas d'effet si G est spécifié dans l'option -I.

Multiplie le nombre de lignes générées par le facteur d'échelle (scale factor). Par exemple, -s 100 va créer 10 millions de lignes dans la table pgbench_accounts. La valeur par défaut est 1. Lorsque l'échelle dépasse 20 000, les colonnes utilisées pour contenir les identifiants de compte (colonnes aid) vont être converties en grands entiers (bigint), de manière à être suffisamment grandes pour contenir l'espace des identifiants de compte.

Crée des contraintes de type clé étrangère entre les tables standards. (Cette option ajoute l'étape d'initialisation f, si elle n'est pas déjà présente.)

Crée un index dans le tablespace spécifié plutôt que dans le tablespace par défaut.

Crée une table partitionnée pgbench_accounts par la méthode NOM. Les valeurs attendues sont range ou hash. Cette option nécessite que --partitions soit différente de zéro. Sans précision, le défaut est range.

Crée une table partitionnée pgbench_accounts avec NUM partitions de taille à peu près égale pour le nombre de clients indiqué par l'échelle. Le défaut est 0, ce qui signifie qu'il n'y a pas de partitionnement.

Crée une table dans le tablespace spécifié plutôt que dans le tablespace par défaut.

Crée toutes les tables en tant que tables non journalisées (unlogged tables) plutôt qu'en tant que tables permanentes.

Ajoute le script interne spécifié à la liste des scripts à exécuter. Les scripts internes disponibles sont tpcb-like, simple-update et select-only. L'utilisation des préfixes non ambigus des noms de scripts internes est acceptée. En utilisant le nom spécial list, la commande affiche la liste des scripts internes, puis quitte immédiatement.

En option, il est possibl d'écrire un poids en entier après @ pour ajuster la probabilité de sélectionner ce script plutôt que les autres. Le poids par défaut est de 1. Voir ci-dessous pour les détails.

Nombre de clients simulés, c'est-à-dire le nombre de sessions concurrentes sur la base de données. La valeur par défaut est à 1.

Établit une nouvelle connexion pour chaque transaction, plutôt que de ne le faire qu'une seule fois par session cliente. C'est une option très utile pour mesurer la surcharge engendrée par la connexion.

Affiche les informations de debug.

Définit une variable à utiliser pour un script personnalisé Voir ci-dessous pour plus de détails. Il est possible d'utiliser plusieurs fois l'option -D.

Ajoute un script de transactions nommé nom_fichier à la liste des scripts à exécuter.

En option, il est possible d'écrire un poids sous la forme d'un entier après le symbole @ pour ajuster la probabilité de sélectionner ce script plutôt qu'unautre. Le poids par défaut est de 1. (Pour utiliser un nom de fichier incluant un caractère @, ajoutez un poids pour qu'il n'y ait pas d'ambiguité, par exemple filen@me@1.) Voir ci-dessous pour les détails.

Nombre de processus utilisés dans pgbench. Utiliser plus d'un thread peut être utile sur des machines possédant plusieurs cœurs. Les clients sont distribués de la manière la plus uniforme possible parmi les threads. La valeur par défaut est 1.

Rapporte les informations sur chaque transaction dans un fichier journal. Voir ci-dessous pour plus de détails.

Les transactions durant plus de limite millisecondes sont comptabilisée et rapportées séparément en tant que late.

Lorsqu'un bridage est spécifié(--rate=... ), les transactions qui accusent un retard sur la planification supérieur à limite millisecondes, et celles qui n'ont aucune chance de respecter la limite de latence ne sont pas du tout envoyées au serveur. Elles sont comptabilisées et rapportées séparément en tant que skipped (ignorées).

Protocole à utiliser pour soumettre des requêtes au serveur :

Comme dans le mode prepared, pgbench réutilise le résultat de l'analyse pour la deuxième itération et les suivantes, pgbench s'exécute plus rapidement dans le mode prepared que dans les autres modes.

Par défaut, le protocole de requête standard est utilisé (voir Chapitre 53 pour plus d'informations).

Ne réalise pas de VACUUM avant de lancer le test. Cette option est nécessaire si vous lancez un scénario de test personnalisé qui n'utilise pas les tables standards pgbench_accounts, pgbench_branches, pgbench_history et pgbench_tellers .

Exécute le script interne simple-update. Raccourci pour -b simple-update.

Affiche un rapport de progression toutes les sec secondes. Ce rapport inclut la durée du test, le nombre de transactions par seconde depuis le dernier rapport et la latence moyenne des transactions, ainsi que la déviation depuis le dernier rapport. Avec le bridage (option -R), la latence est calculée en fonction de la date de démarrage ordonnancée de la transaction et non de son temps de démarrage réel, donc elle inclut aussi la latence moyenne du temps d'ordonnancement.

Rapporte la latence moyenne par instruction (temps d'exécution du point de vue du client) de chaque commande après la fin du benchmark. Voir ci-dessous pour plus de détails.

Exécute les transactions en visant le débit spécifié, au lieu d'aller le plus vite possible (le défaut). Le débit est donné en transactions par seconde. Si le débit visé est supérieur au maximum possible, la limite de débit n'aura aucune influence sur le résultat.

Pour atteindre ce débit, les transactions sont ordonnancées avec une distribution suivant une loi de Poisson. La date de démarrage prévue se calcule depuis le moment où le client a démarré et pas depuis le moment où la dernière transaction s'est achevée. Cette approche signifie que, si une transaction dépasse sa date de fin prévue, un rattrapage est encore possible pour les suivantes.

Lorsque le bridage est actif, la latence de la transaction rapportée en fin de test est calculée à partir des dates de démarrage ordonnancées, c'est-à-dire qu'elle inclut le temps où chaque transaction attend que la précédente se termine. Le temps d'attente est appelé temps de latence d'ordonnancement, et ses valeurs moyenne et maximum sont rapportées séparément. La latence de transaction par rapport au temps de démarrage réel, c'est-à-dire le temps d'exécution de la transaction dans la base, peut être récupérée en soustrayant le temps de latence d'ordonnancement à la latence précisée dans les journaux.

Si l'option --latency-limit est utilisée avec l'option --rate, une transaction peut avoir une telle latence qu'elle serait déjà supérieure à limite de latence lorsque la transaction précédente se termine, car la latence est calculée au moment de la date de démarrage planifiée. Les transactions concernées ne sont pas envoyées à l'instance, elles sont complètement ignorées et comptabilisées séparément.

Une latence de planification élevée est une indication que le système n'arrive pas à traiter les transactions à la vitesse demandée, avec les nombres de clients et threads indiqués. Lorsque le temps moyen d'exécution est plus important que l'intervalle prévu entre chaque transaction, les transactions vont prendre du retard une-à-une, et la latence de planification va continuer de croître tout le long de la durée du test. Si cela se produit, vous devrez réduire le taux de transaction que vous avez spécifié.

Affiche le facteur d'échelle dans la sortie de pgbench. Avec les tests internes, ce n'est pas nécessaire ; le facteur d'échelle approprié sera détecté en comptant le nombre de lignes dans la table pgbench_branches. Toutefois, lors de l'utilisation d'un benchmark avec un scénario personnalisé (option -f), le facteur d'échelle sera affiché à 1 à moins que cette option soit utilisée.

Exécute le script interne select-only. Raccourci pour -b select-only.

Nombre de transactions lancées par chaque client. La valeur par défaut est 10.

Lance le test pour la durée spécifiée en secondes, plutôt que pour un nombre fixe de transactions par client. Les options -t et -T ne sont pas compatibles.

Réalise un VACUUM sur les quatre tables standards avant de lancer le test. Sans l'option -n ou -v, pgbench lancera un VACUUM sur les tables pgbench_tellers et pgbench_branches, puis tronquera pgbench_history.

Taille de l'intervalle d'agrégation (en secondes). Ne peut être utilisée qu'avec l'option -l. Avec cette option, le journal contiendra des résumés par intervalle, comme décrit ci-dessous.

Définit le préfixe des fichiers logs créés par --log. Le défaut est pgbench_log.

Lorsque la progression est affichée (option -P), utilise un horodatage de type timestamp (epoch Unix) au lieu d'un nombre de secondes depuis le début de l'exécution. L'unité est la seconde avec une précision en millisecondes après le point. Ceci aide à comparer les traces générées par différents outils.

Fournit la graine du générateur de nombres aléatoires, qui produira alors une séquence d'états initiaux du générateur, un pour chaque thread. Les valeurs pour graine peuvent être time (par défaut, la graine est basée sur l'heure en cours), rand (utilise une source fortement aléatoire, et tombe en échec si aucune n'est disponible), ou une valeur entière non signée. Le générateur aléatoire est appelé depuis un script pgbench explicitement (fonctions random...) ou implicitement (par exemple l'option --rate l'utilise pour planifier les transactions). Si elle est mise en place explicitement, la valeur utilisée comme graine est affichée sur le terminal. N'importe quelle valeur autorisée pour graine peut aussi être fournie par la variable d'environnement PGBENCH_RANDOM_SEED. Pour garantir que la graine fournie couvre tous les cas d'usage possibles, mettez cette fonction en premier ou utilisez la variable d'environnement.

Placer cette variable explicitement permet de reproduire un run pgbench exactement identique, du moins en ce qui concerne les nombres aléatoires. Comme l'état du générateur aléatoire est géré par thread, pgbench s'exécutera à l'identique s'il y a un client par thread et pas de dépendance externe ou par rapport aux données. D'un point de vue statistique, reproduire des runs est une mauvaise idée, car cela peut masquer la variabilité des performances ou améliorer les performances excessivement, par exemple en appelant les mêmes pages qu'un run précédent. Cependant, ce peut être d'une grande aide pour déboguer, par exemple pour reproduire un cas tordu provoquant une erreur. À utiliser judicieusement.

Taux d'échantillonnage utilisé lors de l'écriture des données dans les journaux, afin d'en réduire la quantité. Si cette option est utilisée, n'y sera écrite que la proportion indiquée des transactions. 1.0 signifie que toutes les transactions seront journalisées, 0.05 signifie que 5% de toutes les transactions le seront.

Pensez à prendre le taux d'échantillonnage en compte en consultant le journal. Par exemple, lorsque vous évaluez le nombre de transactions par seconde, vous devrez multiplier les nombres en conséquence. (Par exemple, avec un taux d'échantillonnage de 0,01, vous n'obtiendrez que 1/100 du tps réel).

Show the actual code of builtin script scriptname on stderr, and exit immediately.

Le nom du serveur de base de données

Le port d'écoute de l'instance sur le serveur de base de données

Le nom de l'utilisateur avec lequel on se connecte

Affiche la version de pgbench puis quitte.

Affiche l'aide sur les arguments en ligne de commande de pgbench puis quitte.

Cette commande peut être utilisée pour marquer la fin de requêtes SQL, prenant ainsi la place du point-virgule final (;).

Quand la commande \gset est utilisée, la requête SQL précédente doit renvoyer une ligne. Les valeurs de ses colonnes sont enregistrées dans des variables nommées d'après les noms de colonnes, préfixées avec prefix, si ce dernier est fourni.

Quand la commande \aset est utilisée, toutes les requêtes (séparées par \;) voient leurs colonnes stockées dans des variables nommées d'après elles, préfixées de prefix s'il est fourni. Si une requête ne retourne aucune ligne, aucune affectation n'est faite. On peut tester l'existence de la variable pour détecter ce cas. Si une requête retourne plus d'une ligne, la dernière valeur est conservée.

\gset et \aset ne peuvent être utilisées en mode pipeline, puisque les résultats des requêtes ne sont pas encore disponibles au moment où la commande en a besoin.

L'exemple suivant place la balance finale du compte provenant de la première requête dans la variable abalance, et remplit les variables p_two et p_three avec les entiers provenant de la troisième requête. Le résultat de la deuxième requête est ignoré. Les résultats des deux dernières requêtes combinées sont stockés dans les variables four et five.

UPDATE pgbench_accounts
  SET abalance = abalance + :delta
  WHERE aid = :aid
  RETURNING abalance \gset
-- compound of two queries
SELECT 1 \;
SELECT 2 AS two, 3 AS three \gset p_
SELECT 4 AS four \; SELECT 5 AS five \aset
       

Ce groupe de commandes implémente des blocs conditionnels imbriquables, de manière similaire au \if expression de psql. Les expressions conditionnelles sont identiques à celles avec \set, les valeurs autres que zéro valant true.

Définit la variable nom_variable à une valeur définie par expression. L'expression peut contenir la constante NULL, les constantes booléennes TRUE et FALSE, des constantes entières comme 5432, des constantes double précision comme 3.14159, des références à des variables :nomvariable, des opérateurs avec leur priorité et leur associativité habituelles en SQL, des appels de fonction, des expressions conditionnelles génériques SQL avec CASE et des parenthèses.

Les fonctions et la plupart des opérateurs retournent NULL en cas d'entrée à NULL.

En ce qui concerne les conditions, les valeurs numériques différentes de zéro valent TRUE, les valeurs numériques à zéro et NULL sont FALSE.

Des constantes entières ou à virgule flottante ainsi que des opérateurs arithmétiques entiers (+, -, * et /), trop larges ou trop petites, renvoient des erreurs de dépassement.

Quand aucune clause finale ELSE n'est fournie à un CASE, la valeur par défaut est NULL.

Exemples :

\set ntellers 10 * :scale
\set aid (1021 * random(1, 100000 * :scale)) % \
           (100000 * :scale) + 1
\set divx CASE WHEN :x <> 0 THEN :y/:x ELSE NULL END
       

Entraîne la suspension de l'exécution du script pendant la durée spécifiée en microsecondes (us), millisecondes (ms) ou secondes (s). Si l'unité n'est pas définie, l'unité par défaut est la seconde. Ce peut être soit un entier constant, soit une référence :nom_variable vers une variable retournant un entier.

Exemple :

\sleep 10 ms
       

Définit la variable nom_variable comme le résultat d'une commande shell nommée commande aves le(s) argument(s) donné(s). La commande doit retourner un entier sur la sortie standard.

commande et chaque argument peuvent être soit une constante de type text, soit une référence :nom_variable à une variable. Si vous voulez utiliser un argument commençant avec un symbole deux-points, écrivez un deux-points supplémentaire au début de l'argument.

Exemple :

\setshell variable_à_utiliser commande argument_litéral :variable
::literal_commencant_avec_deux_points
       

Identique à \setshell, mais le résultat de la commande sera ignoré.

Exemple :

\shell command literal_argument :variable ::literal_starting_with_colon
       

Ces commandes définissent le début et la fin de requêtes SQL. En mode pipeline, celles-ci sont envoyées au serveur sans attendre le résultat des requêtes précédentes. Voir Section 34.5 pour plus de détails. Le mode pipeline impose l'utilisation du protocole de requête étendu.