Dans la
première partie, nous avons parlé des principales innovations et modifications de PostgreSQL 11. Cette fois, nous allons discuter plus en détail de certains points du format question / réponse qui ont été soulevés par meetup.
Quelle est la meilleure façon de transférer un grand tableau de données sous la forme d'un ensemble de paramètres d'entrée pour une procédure stockée dans PL / pgSQL?
Le moyen le plus pratique consiste à créer une table temporaire, à y faire des copies des données, puis à les utiliser dans la procédure.
Moteurs externes (zheap) et développement de PostgreSQL en mémoire
Pas pour toutes les charges de travail, un modèle avec le stockage des anciennes versions d'enregistrements dans la table elle-même convient. Dans tous les autres sous-fichiers (versionionniki), ils sont stockés dans un journal d'annulation. Vous pouvez discuter de la faisabilité, mais l'essentiel est que vous devez stocker les anciens enregistrements quelque part. S'ils ont une courte durée de vie et que quelqu'un s'adresse rarement à eux, le stockage dans la table elle-même est dangereux. Le moteur zheap externe PostgreSQL est une tentative d'EnterpriseDB de créer un moteur de table pour PostgreSQL avec un journal d'annulation. Cela fonctionne, bien qu'il y ait encore quelque chose à améliorer.
Qui travaille avec Mme SQL en mode SNAPSHOT Isolation Level, sait qu'il a tempdb, où il met les anciennes versions, et est équipé d'un aspirateur complètement vide pour nettoyer tempdb. En revanche, la communauté demande de créer des tables en mémoire dans PostgreSQL. Cela peut être fait assez facilement: tmpfs, et c'est tout. Dans PostgreSQL Pro, même sorti la première version pilote, vous pouvez essayer.
PostgreSQL n'a jamais eu de moteurs de plug-in. Il y avait des index enfichables qui utilisaient un WAL commun. PostgreSQL a beaucoup à brancher et peu à remplacer à la volée. Par exemple, l'exécuteur n'est pas désactivé, mais vous pouvez déjà y utiliser des nœuds personnalisés que vous programmez vous-même. Les optimiseurs de PostgreSQL sont complètement enfichables. Vous pouvez écrire le vôtre et utiliser PostgreSQL comme interprète de vos requêtes. L'analyseur SQL ne peut pas être connecté.
Les moteurs veulent se connecter dans trois directions:
- moteur avec journal d'annulation
- en mémoire
- stockage de colonnes pour les requêtes OLAP
Postgres Pro est en pourparlers avec EnterpriseDB sur la façon de créer une API pour connecter tout cela.
À propos de la clé étrangère
La clé étrangère à l'intérieur de PostgreSQL est implémentée par des déclencheurs. Vous pouvez écrire votre déclencheur qui implémentera tout type de fonctionnalité. Toutes les restrictions possibles doivent être effectuées dans le déclencheur. La logique dans les déclencheurs n'est pas particulièrement nécessaire à conserver, mais vérifiez tout - c'est nécessaire.
Postgres Pro prévoit-il de faire du SaaS ou du PaaS?
Postgres Pro prévoit de rendre PostgreSQL plus optimisé pour le cloud, en particulier pour implémenter des modifications dynamiques des tampons de partage, afin de réduire le nombre de paramètres qui nécessitent un redémarrage de PostgreSQL. Ils ne vont pas construire le cloud eux-mêmes.
Comment configurer un lecteur pour que l'indexation parallèle fonctionne plus rapidement? Quel est le meilleur, plusieurs disques durs ou un SSD?
Mieux vaut quelques SSD. Plus le matériel offre d'options de parallélisation, mieux c'est. Si vous avez un disque, pas assez de mémoire et un processeur, la parallélisation ne vous aidera pas. Mais les SSD ont une particularité: ils commencent à ralentir si plus de 80% du volume est occupé. Par conséquent, n'oubliez pas de régler le trim, sinon la limite de 80% se situera autour de 50%.
Gestion du dictionnaire et ajout de mots dans la recherche en texte intégral
Si vous utilisez un sort ou une boule de neige, changez simplement le dictionnaire des mots vides. Le problème est que si vous avez ajouté un mot d'arrêt, il n'y a aucun intérêt à l'indexation. Cela peut se faire lentement. Un mot d'arrêt sera rejeté d'une demande et ne sera jamais recherché. Et si vous avez supprimé le mot d'arrêt, alors nulle part dans la collection, il n'est pas là et vous devez le réindexer. Le problème n'est pas dans le dictionnaire, mais dans le fait que vous l'avez déjà utilisé et enregistré vos connaissances.
De plus, dans de nombreux cas, vous pouvez utiliser la fonction peu connue ts_rewrite, qui vous permet de remplacer une partie de la demande par une autre demande. Par exemple, lorsque le sous-marin de Koursk s'est noyé, tout le monde s'est précipité pour chercher des informations à ce sujet. Fedor Sigaev travaillait alors à la randonnée et à la demande de "Koursk", des informations sur la ville ont été diffusées. Ils ont rapidement fait une substitution: sur ce mot, donnez des informations sur le sous-marin. Mais alors les utilisateurs ont commencé à maudire, qui s'intéressaient au village lui-même. Je ne sais pas s’ils ont réalisé ou non, mais il a fallu introduire la «ville de Koursk». De telles substitutions permettent d'effectuer ts_rewrite. En outre, la fonction peut être utilisée pour une transition en douceur pendant la période de modifications du dictionnaire.
Bien sûr, changer l'analyseur et les dictionnaires sont des tâches complexes. Les langues avec différents alphabets, comme le russe et l'anglais, s'entendent bien. Aujourd'hui, les textes français-anglais sont bien pires. Il n'est pas clair à quelle langue un mot fait référence, qui est écrit de la même manière, mais dans une langue, c'est un mot d'arrêt, et dans une autre il ne l'est pas. Postgres Pro travaille actuellement sur des dictionnaires de réglage fin pour décrire des configurations plus complexes.
Couverture des indices et mise à jour à chaud
C’est complètement amis. Vrai, si au moins un champ est mis à jour dans l'index de couverture, alors l'index se comportera comme d'habitude, tout sera remplacé.
Impossibilité de créer des tables temporaires lors de l'exécution de requêtes en veille
PostgreSQL ne stocke pas les connaissances des tables dans le répertoire système, mais il existe un correctif qui transfère les connaissances dans le répertoire système. Par conséquent, avec ce correctif, vous pouvez utiliser des tables temporaires. Mais alors un autre problème se pose: il n'y a pas de transactions en attente. Pour travailler avec une table temporaire, vous devrez utiliser deux fois l'ID de transaction virtuelle, qui s'applique uniquement aux tables temporaires, et non aux principales qui proviennent de l'assistant. Et lorsque vous regardez un nombre 32 bits, ce seront deux nombres différents.
Postgres Pro dispose également d'un module pg_variables, qui fonctionne également en mode veille. Ce n'est pas une table temporaire, mais les fonctionnalités nécessaires peuvent être représentées.
Implémenter l'index de cluster
Postgres Pro a eu plusieurs tentatives pour l'implémenter. Vous pouvez maintenant entrer l'index de la table de cluster et la table sera dans le même ordre. A souffert de la façon de maintenir une table dans un état en cluster. Nous avons essayé différentes approches, mais invariablement l'insertion dans une telle table était très coûteuse. Et ce n'est intéressant pour personne. Par conséquent, jusqu'à présent, il a été conclu qu'il était nécessaire de passer aux tables organisées d'index.
Facteur d'échelle à vide automatique recommandé
Recommande généralement de régler 1 à 5%. Mais c'est complètement facultatif. Pour les petites tables, dans lesquelles, malgré les changements, en moyenne, la même distribution reste, une grande valeur peut être définie. Si le tableau est grand et rarement réapprovisionné, mais à juste titre, avec un fort changement de distribution, vous devrez inventer autre chose. Tout dépend de la distribution de vos données.
Conseils dans les requêtes complexes
Dans Oracle, avec des requêtes complexes, vous devez périodiquement aider avec des conseils, car des analyses complètes soudaines se produisent. Il y a des indices dans Postgres Pro, assez moroses, mais vous pouvez les obtenir. Cependant, il n'y a aucune indication dans PostgreSQL standard, et il est peu probable qu'ils apparaissent. Si vous avez des indices intégrés, les utilisateurs, confrontés à un problème d'optimiseur, insèrent des indices, se calment et ne signalent aucun problème. Le développement de l'optimiseur s'arrête.
Soit dit en passant, l'optimiseur PostgreSQL a un problème. Lorsqu'il estime un échantillon à partir d'un tableau, même pour un montant plus ou moins raisonnable, il devine avec une certaine erreur. Ensuite, il commence à se connecter, le résultat est connecté à autre chose, l'erreur s'accumule et au troisième ou au quatrième niveau, PostgreSQL manque beaucoup.
Il existe un tel paramètre - limite d'effondrement des jointures. PostgreSQL trie les JOIN pour une utilisation plus efficace, mais la limite de tri par défaut est 8. S'il y a plus de 8 JOIN dans une rangée, le système ne les triera pas et il y aura une dépendance à l'ordre JOIN dans la requête.
Il existe également un optimiseur génétique avec différents paramètres. Vous pouvez activer divers paramètres dans une session et décrire plus ou moins comment la demande doit être exécutée. En utilisant cet ordre, à l'aide de crochets, vous pouvez définir l'arrêt de certaines opérations, le même balayage sec. Une autre option consiste à insérer certains paramètres dans les fonctions. Dans un sens, ce sont aussi des indices. Pas très pratique, mais au moins quelque chose.