PostgreSQL
 sql >> डेटाबेस >  >> RDS >> PostgreSQL

आईडी के आधार पर लाखों पंक्तियों को हटाने का सबसे अच्छा तरीका

यह सब निर्भर करता है...

  • मान लें कि समवर्ती लेखन पहुंच नहीं है शामिल तालिकाओं के लिए या आपको तालिकाओं को विशेष रूप से लॉक करना पड़ सकता है या यह मार्ग आपके लिए बिल्कुल भी नहीं हो सकता है।

  • सभी अनुक्रमणिका हटाएं (संभवत:हटाने के लिए आवश्यक अनुक्रमणिका को छोड़कर)।
    बाद में उन्हें फिर से बनाएं। यह आमतौर पर अनुक्रमणिका में वृद्धिशील अद्यतनों की तुलना में बहुत तेज़ होता है।

  • जांचें कि क्या आपके पास ऐसे ट्रिगर हैं जिन्हें सुरक्षित रूप से अस्थायी रूप से हटाया / अक्षम किया जा सकता है।

  • क्या विदेशी कुंजियाँ आपकी तालिका का संदर्भ देती हैं? क्या उन्हें मिटाया जा सकता है? अस्थायी रूप से हटाया गया?

  • आपकी ऑटोवैक्यूम सेटिंग के आधार पर यह हो सकता है VACUUM ANALYZE run चलाने में मदद करें ऑपरेशन से पहले।

  • मैनुअल के संबंधित अध्याय में सूचीबद्ध कुछ बिंदु डेटाबेस को पॉप्युलेट करना आपके सेटअप के आधार पर भी काम आ सकता है।

  • यदि आप टेबल के बड़े हिस्से को हटा देते हैं और बाकी रैम में फिट हो जाते हैं, तो सबसे तेज़ और आसान तरीका यह हो सकता है:

BEGIN; -- typically faster and safer wrapped in a single transaction

SET LOCAL temp_buffers = '1000MB'; -- enough to hold the temp table

CREATE TEMP TABLE tmp AS
SELECT t.*
FROM   tbl t
LEFT   JOIN del_list d USING (id)
WHERE  d.id IS NULL;      -- copy surviving rows into temporary table

TRUNCATE tbl;             -- empty table - truncate is very fast for big tables

INSERT INTO tbl
SELECT * FROM tmp;        -- insert back surviving rows.
-- ORDER BY ?             -- optionally order favorably while being at it

COMMIT;

इस तरह आपको विचारों, विदेशी कुंजियों या अन्य निर्भर वस्तुओं को फिर से बनाने की आवश्यकता नहीं है। और आपको बिना ब्लोट के एक प्राचीन (क्रमबद्ध) तालिका मिलती है।

temp_buffers के बारे में पढ़ें मैनुअल में सेटिंग। यह विधि तब तक तेज़ है जब तक तालिका स्मृति में फिट हो जाती है, या कम से कम इसका अधिकांश भाग। यदि आपका सर्वर इस ऑपरेशन के बीच में क्रैश हो जाता है तो ट्रांजेक्शन रैपर डेटा खोने से बचाव करता है।

VACUUM ANALYZE चलाएं उसके बाद। या VACUUM FULL ANALYZE यदि आप इसे न्यूनतम आकार में लाना चाहते हैं (एक्सक्लूसिव लॉक लेता है)। बड़ी तालिकाओं के लिए विकल्पों पर विचार करें CLUSTER / pg_repack या समान:

  • पोस्टग्रेज टाइमस्टैम्प क्वेरी श्रेणी को ऑप्टिमाइज़ करें

छोटी तालिकाओं के लिए, एक साधारण DELETE TRUNCATE . के बजाय अक्सर तेज़ होता है:

DELETE FROM tbl t
USING  del_list d
WHERE  t.id = d.id;

पढ़ें नोट्स TRUNCATE . के लिए अनुभाग मैनुअल में। विशेष रूप से (जैसा कि पेड्रो ने भी अपनी टिप्पणी में बताया):

<ब्लॉकक्वॉट>

TRUNCATE अन्य तालिकाओं से विदेशी-कुंजी संदर्भ वाली तालिका पर उपयोग नहीं किया जा सकता है, जब तक कि ऐसी सभी तालिकाओं को भी उसी आदेश में छोटा नहीं किया जाता है। [...]

और:

<ब्लॉकक्वॉट>

TRUNCATE किसी भी ON DELETE को सक्रिय नहीं करेगा ट्रिगर जो टेबल के लिए मौजूद हो सकते हैं।



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. रेक डीबी:थ्रो डेटाबेस बनाएं पोस्टग्रेस्क्ल के साथ त्रुटि मौजूद नहीं है

  2. एक JSONB फ़ील्ड से समेकित कुंजी/मान जोड़े को फ़्लैट करें?

  3. फ़ंक्शन से टेक्स्ट आउटपुट को नई क्वेरी के रूप में उपयोग करें

  4. पोस्टग्रेज जोंस कॉलम में नेस्टेड सरणियों को कैसे क्वेरी करें?

  5. डेटा अंतराल के आधार पर समूहित करें