Oui, vous pouvez!! La solution doit être simple, sûre et performante ...
Je suis nouveau dans postgresql, mais il semble que vous puissiez créer des colonnes calculées en utilisant un index d'expression , associé à une vue (la vue est facultative, mais rend la vie un peu plus facile).
Supposons que mon calcul soit md5(some_string_field)
, alors je crée l'index comme:
CREATE INDEX some_string_field_md5_index ON some_table(MD5(some_string_field));
Désormais, toutes les requêtes qui agissent MD5(some_string_field)
utiliseront l'index plutôt que de le calculer à partir de zéro. Par exemple:
SELECT MAX(some_field) FROM some_table GROUP BY MD5(some_string_field);
Vous pouvez vérifier cela avec Expliquer .
Cependant, à ce stade, vous comptez sur les utilisateurs de la table sachant exactement comment construire la colonne. Pour vous simplifier la vie, vous pouvez créer un VIEW
sur une version augmentée de la table d'origine, en ajoutant la valeur calculée en tant que nouvelle colonne:
CREATE VIEW some_table_augmented AS
SELECT *, MD5(some_string_field) as some_string_field_md5 from some_table;
Désormais, toutes les requêtes utilisant some_table_augmented
pourront être utilisées some_string_field_md5
sans se soucier de son fonctionnement .. elles obtiennent juste de bonnes performances. La vue ne copie aucune donnée de la table d'origine, elle est donc bonne en termes de mémoire et de performances. Notez cependant que vous ne pouvez pas mettre à jour / insérer dans une vue, uniquement dans la table source, mais si vous le souhaitez vraiment, je pense que vous pouvez rediriger les insertions et les mises à jour vers la table source en utilisant des règles (je peux me tromper sur ce dernier point car Je ne l'ai jamais essayé moi-même).
Edit: il semble que si la requête implique des index concurrents, le moteur de planification peut parfois ne pas utiliser du tout l'index d'expression. Le choix semble dépendre des données.