Généralement, le planificateur de requêtes Postgres fait des vues "en ligne" pour optimiser l'ensemble de la requête. Par documentation :
Mais je ne pense pas que Postgres soit assez intelligent pour conclure qu'il peut atteindre le même résultat à partir de la table de base sans éclater les lignes.
Vous pouvez essayer cette requête alternative avec un LATERAL rejoindre. C'est plus propre :
CREATE OR REPLACE VIEW runinfo.v_mt_count_by_day AS
SELECT m.run_id, m.type, m.brand
, m.start_day + c.rn - 1 AS row_date
, c.row_count
FROM runinfo.mt_count_by_day m
LEFT JOIN LATERAL unnest(m.counts) WITH ORDINALITY c(row_count, rn) ON true;
Il précise également que l'un des (end_day , start_day ) est redondant.
Utilisation de LEFT JOIN car cela pourrait permettre au planificateur de requêtes d'ignorer la jointure de votre requête :
SELECT DISTINCT type FROM v_mt_count_by_day;
Sinon (avec un CROSS JOIN ou INNER JOIN ) il doit évaluer la jointure pour voir si les lignes de la première table sont éliminées.
Au fait, c'est :
SELECT DISTINCT type ...
non :
SELECT DISTINCT(type) ...
Notez que cela renvoie une date au lieu de l'horodatage dans votre original. Plus facile, et je suppose que c'est ce que vous voulez de toute façon ?
Nécessite Postgres 9.3+ Détails :
ROWS FROM
dans Postgres 9.4+
Pour exploser les deux colonnes en parallèle en toute sécurité :
CREATE OR REPLACE VIEW runinfo.v_mt_count_by_day AS
SELECT m.run_id, m.type, m.brand
t.row_date::date, t.row_count
FROM runinfo.mt_count_by_day m
LEFT JOIN LATERAL ROWS FROM (
unnest(m.counts)
, generate_series(m.start_day, m.end_day, interval '1d')
) t(row_count, row_date) ON true;
Le principal avantage :cela ne déraillerait pas dans un produit cartésien si les deux SRF ne renvoyaient pas le même nombre de lignes. Au lieu de cela, les valeurs NULL seraient remplies.
Encore une fois, je ne peux pas dire si cela aiderait le planificateur de requêtes avec un plan plus rapide pour le DISTINCT type sans test.
