में जेसन_एजीजी प्रदर्शन को समझना मैं समान डीबी प्रश्नों के बीच देख रहे पर्याप्त गति अंतर को समझने की कोशिश कर रहा हूं, और मैं कुछ अंतर्दृष्टि की उम्मीद कर रहा था कि कुछ समेकन दूसरों की तुलना में इतनी धीमी क्यों हैं।पोस्टग्रेस 9.5
मैं एक साधारण दस्तावेज़ पुनर्प्राप्ति क्वेरी के साथ कुछ गति मुद्दों पर ध्यान, और यह का एक बड़ा हिस्सा 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;
आसपास 500ms की कुल क्वेरी समय दिखाता है, इस बात का ओवर 400 मि.से साथ
GroupAggregate (cost=11921.58..12607.34 rows=17540 width=1553) (actual time=78.818..484.071 rows=17455 loops=1)
बस स्विचिंग json_aggarray_agg को 150ms रेंज में नीचे कुल समय लाता है, हालांकि समय के बारे में आधे अभी भी एकत्रित खर्च किया जाता है: एकत्रीकरण कदम में बिताए
GroupAggregate (cost=11921.58..12607.34 rows=17540 width=1553) (actual time=81.975..147.207 rows=17455 loops=1)
समूहीकरण या एकत्रीकरण के बिना क्वेरी प्रदर्शन, कुल समय 25ms करने के लिए नीचे लाता है, हालांकि कि containers के परिवर्तनशील वापसी होगी कि कितने content_items प्रत्येक में थे पर निर्भर करता है।
क्या इस तरह के जुर्माना लगाने के लिए json_agg का कोई कारण है? क्या उनके content_items के साथ container पंक्तियों की एक सेट संख्या पुनर्प्राप्त करने का एक प्रभावी तरीका है, और बस एप्लिकेशन परत में कुल मिलाकर?