आपको production में मौजूद बीस करोड़ rows पर एक नया column भरना है। आप इसे कैसे चलाएंगे?

कभी एक ही update statement से नहीं। column को nullable और बिना default rewrite के जोड़ें, फिर primary key के क्रम में छोटे बैचों में backfill करें, हर बैच को commit करते हुए, बीच में थोड़ी नींद और replication lag की जांच के साथ। प्रगति दर्ज करके job को resumable बनाएं, उसे कम ट्रैफ़िक के समय चलाएं, और एप्लिकेशन से नई तथा अपडेट होने वाली rows में नया column लिखवाएं ताकि backfill को सिर्फ इतिहास पकड़ना पड़े।

बीस करोड़ rows छूने वाला एक update locks पकड़ता है, बेहिसाब write ahead log बनाता है, और replicas को इतना पीछे धकेल देता है कि reads बासी डेटा देने लगती हैं, तो कुछ crash न होने पर भी साइट को नुकसान होता है। इसके बजाय मैं column को nullable जोड़ता हूं, जो आजकल के Postgres पर सस्ता है क्योंकि इससे टेबल दोबारा नहीं लिखी जाती, और पहले वह एप्लिकेशन बदलाव deploy करता हूं जो हर insert तथा update पर उसे भर देता है। इसका मतलब है कि backfill को सिर्फ इतिहास संभालना है, और इतिहास हिलता नहीं। फिर job primary key पर कुछ हज़ार के बैचों में चलती है, हर बैच commit करती है, आखिरी पूरा हुआ id दर्ज करती है ताकि restart के बाद वहीं से चले, और replication lag या डेटाबेस लोड हद पार करते ही रुक जाती है। मैं इसे जितनी तेज़ हो सके उतनी तेज़ नहीं, बल्कि rate limit के साथ चलाता हूं। खत्म होने पर मैं counts और नमूना जांच से पक्का करता हूं कि कुछ null नहीं बचा, फिर एक flag के पीछे reads को नए column पर मोड़ता हूं, और उसके बाद ही not null constraint जोड़ता हूं, अलग से validate करके ताकि लंबा lock न लगे।