Est-ce que beaucoup de somme répétée (x) dans différents cols font un Select plus lent?

Question

J'ai une très grande table avec des dizaines de colonnes et beaucoup de rangées. Appelons cette table FT. Tous les jours, je lance un script qui lit les données de la table FT, effectue des calculs et met à jour une table plus petite (table FA) que j'utilise pour générer des rapports.

La requête que la mise à jour FA est quelque chose comme:

INSERT INTO FA (A, B, C) 
    (SELECT sum(X), sum(x) * sum(y), sum(x) + sum(z)) group by.. 

Comme je l'utilise somme (x) un grand nombre de fois, ce sera plus rapide si je crée une table temporaire avec la somme (x), somme (y) et sum (z) et l'utiliser pour mettre à jour ma table FA?

Answer 1

chaque db je sais a ce genre de thème optimisé de sorte que les valeurs ne sont calculées qu'une seule fois.

Si vous n'êtes pas sûr, consultez le plan d'exécution et les lectures de la requête en cours et votre requête de table temporaire.

Answer 2

En règle générale, le temps nécessaire pour récupérer les données à partir du disque est la plus lente opération une base de données fait (en particulier sur une grande table)

j'attendre relativement des opérations arithmétiques straight-forward comme celles-ci être négligeable en comparaison.

Answer 3

Benchmark votre requête sur:

insert into fa (a, b, c) 
select sum_x, sum_x * sum_y, sum_x * sum_z 
    from (select sum(x) as sum_x, sum(y) as sum_y, sum(z) as sum_z 
      from my_table 
     group by my_grouping_columns) 

Mon forte suspicion est que d'Oracle obtenu pour construire l'ensemble intermédiaire d'abord quel que soit - les sommes que regroupées par - puis transformer ce dans le jeu de résultats final, quel que soit.

Il ne sera certainement pas plus facile ou plus rapide de forcer Oracle à matérialiser le jeu de résultats intermédiaire dans une table temporaire globale; vous ajoutez des E/S de chemin direct sans avoir une bonne raison de le faire. Cela dit, si l'ensemble de résultats intermédiaires est coûteux à construire et utilisé dans plusieurs insertions, il peut être utile de le matérialiser dans une table temporaire.

Answer 4

Considérant que vous avez marqué ce poste avec data-warehouse et datamart, je ne peux que supposer que votre table de FT est une sorte de fait et que la requête ressemble à quelque chose comme:

select 
    CalendarMonth 
    , sum(x) as Tot_1 
    , sum(x) * sum(y) as Tot_2 
    , sum(x) + sum(z) as Tot_3 
from FT   as f 
join dimDate as d on d.DateKey = f.DateKey 
join dimUser as u on u.UserKey = f.UserKey 
join dimProduct as p on p.ProductKey = f.ProductKey 
where CalendarYear between 2008 and 2010 
    and Country = 'United States' 
    and ProductCategory = 'Cool Gadget' 
    and UserGender = 'Female' 
group by CalendarMonth ; 

Quelle est exactement comment un agrégation sur les mesures dans une table de faits devrait ressembler. Maintenant, à des fins de création de rapports, il semble que vous ayez une table d'agrégation (FA) pour accélérer les rapports. Je peux seulement deviner que l'entrepôt est chargé pendant la nuit et que votre requête prépare l'agrégation parfois le matin, avant les heures d'ouverture, de sorte qu'elle s'exécute une fois par jour - ou du moins est supposée le faire. Si cette requête prend trop de temps à s'exécuter, pensez à ajouter quelques champs clés à votre table d'agrégation (FA), généralement DateKey, puis à mettre à jour la table FA périodiquement. Par exemple, si vous avez 10 000 ventes par jour que la requête ci-dessus somme ~ 300 000 lignes pour chaque mois. Si la table d'agrégation est agrégée par jour, il faut une somme de 10 000 lignes une fois par jour pour mettre à jour la table et une somme de seulement 30 lignes par mois pour un rapport. Pour résumer, afin d'accélérer les requêtes d'agrégation de faits se concentrer sur le nombre de lignes qui sont agrégées - pas sur les fonctions d'agrégation. Assurez-vous également que les tables de dimension possèdent des index sur les colonnes mentionnées dans la clause WHERE de la requête.

Certes, j'ai peut-être supposé trop ici, donc cela peut ou ne pas être utile.