6
मेरे पास एक डिलीट क्वेरी है जिसे मुझे PostgreSQL 9.0.4 पर चलाने की आवश्यकता है। मुझे लगता है कि यह निष्पादक है जब तक कि यह उप-चयन क्वेरी में 524,28 9 पंक्तियों को हिट नहीं करता है।पोस्टग्रेज़ मटेरियलाइज डिलीट क्वेरी में खराब प्रदर्शन का कारण बनता है
उदाहरण के लिए, 524,288 में कोई materialized इस्तेमाल किया दृश्य है और लागत बहुत अच्छा लग रहा है:
explain DELETE FROM table1 WHERE pointLevel = 0 AND userID NOT IN
(SELECT userID FROM table2 fetch first 524288 rows only);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Delete (cost=13549.49..17840.67 rows=21 width=6)
-> Index Scan using jslps_userid_nopt on table1 (cost=13549.49..17840.67 rows=21 width=6)
Filter: ((NOT (hashed SubPlan 1)) AND (pointlevel = 0))
SubPlan 1
-> Limit (cost=0.00..12238.77 rows=524288 width=8)
-> Seq Scan on table2 (cost=0.00..17677.92 rows=757292 width=8)
(6 rows)
हालांकि, जैसे ही मैंने 524,289 मारा, materialized दृश्य खेलने में आता है और हटाना क्वेरी ज्यादा हो जाता है अधिक महंगा:
SELECT s.userid
FROM table1 s
LEFT JOIN table2 p ON s.userid=p.userid
WHERE p.userid IS NULL AND s.pointlevel=0
explain DELETE FROM table1 WHERE pointLevel = 0 AND userID NOT IN
(SELECT userID FROM table2 fetch first 524289 rows only);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Delete (cost=0.00..386910.33 rows=21 width=6)
-> Index Scan using jslps_userid_nopt on table1 (cost=0.00..386910.33 rows=21 width=6)
Filter: ((pointlevel = 0) AND (NOT (SubPlan 1)))
SubPlan 1
-> Materialize (cost=0.00..16909.24 rows=524289 width=8)
-> Limit (cost=0.00..12238.79 rows=524289 width=8)
-> Seq Scan on table2 (cost=0.00..17677.92 rows=757292 width=8) (7 rows)
मैं एक के बजाय उप चयन क्वेरी में शामिल हों का उपयोग करके समस्या के काम
हालांकि, मुझे अभी भी यह समझने में दिलचस्पी है कि भौतिकता इतनी भारी प्रदर्शन क्यों करती है।