Comprendere le prestazioni di json_agg in Postgres 9.5

Question

Sto cercando di capire differenze sostanziali di velocità che vedo tra query DB simili, e speravo di capire perché alcune aggregazioni sono molto più lente di altre.

ho notato alcuni problemi di velocità con una semplice query recupero dei documenti, e una parte sostanziale di esso sembra essere la funzione json_agg:

SELECT containers.*, json_agg(content_items.*) as items FROM containers 
INNER JOIN content_items ON containers.id = content_items.container_id 
GROUP BY containers.id 
ORDER BY containers.order_date DESC, containers.id DESC 
LIMIT 25 OFFSET 0; 

Indica un tempo totale di query di circa 500 ms, con più di 400 ms di quel trascorso nella fase di aggregazione:

GroupAggregate (cost=11921.58..12607.34 rows=17540 width=1553) (actual time=78.818..484.071 rows=17455 loops=1) 

semplicemente passare alla json_aggarray_agg porta il tempo totale giù nella gamma 150ms, anche se circa la metà del tempo è ancora trascorso aggregazione:

GroupAggregate (cost=11921.58..12607.34 rows=17540 width=1553) (actual time=81.975..147.207 rows=17455 loops=1) 

Esecuzione della query senza raggruppamento o aggregazione porta il tempo totale fino a 25 ms, anche se sarebbe restituire un numero variabile di containers seconda di quanti content_items erano in ogni.

C'è un motivo per il json_agg di imporre tale penalità? Esiste un modo performante per recuperare un numero impostato di righe container, insieme a tutti i loro content_items e semplicemente aggregare nel livello applicazione?

Answer 1

Si potrebbero fare due query: la prima otterrebbe i contenitori appropriati, ordinati e limitati a 25. Il secondo otterrebbe content_items utilizzando una clausola where-in. L'applicazione potrebbe quindi filtrare e mappare il contenuto nei contenitori appropriati.