ಒಂದು ಸರಳ ಡೇಟಾಬೇಸ್ ಟ್ರಿಕ್ ಇಮೇಲ್ ಸಂಸ್ಕರಣೆಯನ್ನು 18 ಪಟ್ಟು ವೇಗಗೊಳಿಸಿದ್ದು ಹೇಗೆ

ಇಮೇಲ್ ಸಿಂಕ್ ಸಮಸ್ಯೆ

ಫೈಲ್‌ನಿಂದ ಡೇಟಾಬೇಸ್‌ಗೆ ಇಮೇಲ್ ವಿಳಾಸಗಳನ್ನು ಸಿಂಕ್ ಮಾಡುವ ಆ್ಯಪ್ ಒಂದನ್ನು ನೀವು ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ಕೆಲಸ: ಫೈಲ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಇಮೇಲ್‌ಗಳನ್ನು ಸಕ್ರಿಯ (active) ಎಂದು ಗುರುತಿಸುವುದು, ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿದ್ದ ಆದರೆ ಇನ್ನು ಮುಂದೆ ಫೈಲ್‌ನಲ್ಲಿ ಇಲ್ಲದಿರುವ ಯಾವುದೇ ಇಮೇಲ್‌ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು (deactivate), ಮತ್ತು ಆಡಿಟಿಂಗ್‌ಗಾಗಿ ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಯ ದಾಖಲೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು. ಇದು ಸರಳವೆನಿಸುತ್ತದೆ—ಆದರೆ ನೀವು 100,000 ವಿಳಾಸಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುವಾಗ, ಈ ಸರಳ ವಿಧಾನವೇ ಒಂದು ತೊಡಕಾಗುತ್ತದೆ (bottleneck).

Yaroslav Podorvanov ಎಂಬ ಡೆವಲಪರ್ ಇತ್ತೀಚೆಗೆ ಈ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು 90 ಸೆಕೆಂಡುಗಳು ಹೇಗೆ ತೆಗೆದುಕೊಂಡಿತು—ಮತ್ತು PostgreSQL ತಂತ್ರವನ್ನು ಬಳಸಿ ಅದನ್ನು ಮರುಬರೆದಾಗ ಅದು ಕೇವಲ 5 ಸೆಕೆಂಡುಗಳಿಗೆ ಹೇಗೆ ಕಡಿಮೆಯಾಯಿತು ಎಂಬುದನ್ನು ಹಂಚಿಕೊಂಡಿದ್ದಾರೆ. 8 July 2026 ರಂದು, ಈ ವಿಧಾನವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮೌಲ್ಯಯುತವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಡೇಟಾಬೇಸ್‌ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದರ ಕುರಿತು ಪ್ರಮುಖವಾದದ್ದನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ: ನಿಜವಾದ ವೆಚ್ಚವು ಸಾಮಾನ್ಯವಾಗಿ ಭಾರಿ ಕೆಲಸವಲ್ಲ—ಅದು ನಿಮ್ಮ ಕೋಡ್ ಮತ್ತು ಡೇಟಾಬೇಸ್ ನಡುವಿನ ಸಂಭಾಷಣೆಯಾಗಿದೆ.

ನಿಧಾನಗತಿಯ ಆವೃತ್ತಿಯು ಹೇಗೆ ಕೆಲಸ ಮಾಡಿತು

ಮೂಲ ಪರಿಹಾರವು ಕೆಲಸವನ್ನು ಪ್ರತ್ಯೇಕ ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಿತು:

1. ಫೈಲ್‌ನಿಂದ ಹೊಸ ಇಮೇಲ್ ವಿಳಾಸಗಳನ್ನು ಸೇರಿಸಿ (Insert) ಅಥವಾ ಅಪ್‌ಡೇಟ್ ಮಾಡಿ
2. ಫೈಲ್‌ನಲ್ಲಿ ಇಲ್ಲದ ಯಾವುದೇ ಇಮೇಲ್ ವಿಳಾಸಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ
3. ಆಡಿಟಿಂಗ್‌ಗಾಗಿ ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಯನ್ನು ಹಿಸ್ಟರಿ ಟೇಬಲ್‌ನಲ್ಲಿ ದಾಖಲಿಸಿ

ಪ್ರತಿಯೊಂದು ಹಂತವೂ ತನ್ನದೇ ಆದ ಡೇಟಾಬೇಸ್ ಕ್ವೆರಿಯಾಗಿತ್ತು. ಇದರರ್ಥ ಕೋಡ್ ಹೀಗೆ ಮಾಡಬೇಕಾಗಿತ್ತು:

• ಇಮೇಲ್ ಪಟ್ಟಿಯನ್ನು ಡೇಟಾಬೇಸ್‌ಗೆ ಕಳುಹಿಸುವುದು
• ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯುವುದು
• ಬದಲಾದವುಗಳ ID ಗಳನ್ನು ಪಡೆಯುವುದು
• ಆ ID ಗಳನ್ನು ಮತ್ತೆ ಡೇಟಾಬೇಸ್‌ಗೆ ಕಳುಹಿಸುವುದು
• ಮತ್ತೆ ಕಾಯುವುದು
• ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವಿಕೆಗೆ ಮತ್ತೆ ಪುನರಾವರ್ತಿಸುವುದು
• ಹಿಸ್ಟರಿ ದಾಖಲೆಗಳಿಗಾಗಿ ಮತ್ತೆ ಪುನರಾವರ್ತಿಸುವುದು

100,000 ವಿಳಾಸಗಳೊಂದಿಗೆ, ಆ ಎಲ್ಲಾ ಕಾಯುವಿಕೆ ಒಟ್ಟಾಗಿ ಒಟ್ಟು 90 ಸೆಕೆಂಡುಗಳಾಯಿತು.

CTE ಪರಿಹಾರ

Common Table Expression (CTE) ಎಂಬುದು ಸಂಕೀರ್ಣವಾದ ಕ್ವೆರಿಯನ್ನು ಹೆಸರಿಸಲಾದ, ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಲು PostgreSQL ಒದಗಿಸುವ ಮಾರ್ಗವಾಗಿದೆ—ಇದೆಲ್ಲವೂ ಒಂದೇ ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಾಚರಣೆಯೊಳಗೆ ನಡೆಯುತ್ತದೆ. ಡೇಟಾಬೇಸ್‌ಗೆ ಐದು ಪ್ರತ್ಯೇಕ ಟ್ರಿಪ್‌ಗಳನ್ನು ಮಾಡುವ ಬದಲು, Podorvanov ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಕ್ವೆರಿಗೆ ಸ್ಥಳಾಂತರಿಸಿದರು:

WITH
  data (email) AS (
    SELECT UNNEST(@emails::VARCHAR[])
  ),
  deactivated (id) AS (
    UPDATE rtt_emails
    SET active = FALSE, updated_at = @now::TIMESTAMP
    WHERE email NOT IN (SELECT email FROM data)
    AND active = TRUE
    RETURNING id
  ),
  activated (id) AS (
    INSERT INTO rtt_emails (email, active, created_at, updated_at)
    SELECT email, TRUE, @now::TIMESTAMP, @now::TIMESTAMP
    FROM data
    ON CONFLICT (email) DO UPDATE
    SET active = EXCLUDED.active, updated_at = EXCLUDED.updated_at
    WHERE rtt_emails.active IS DISTINCT FROM EXCLUDED.active
    RETURNING id
  ),
  deactivated_history AS (
    INSERT INTO rtt_email_history (email_id, active, file_id, created_at)
    SELECT id, FALSE, @file_id::BIGINT, @now::TIMESTAMP
    FROM deactivated
  ),
  activated_history AS (
    INSERT INTO rtt_email_history (email_id, active, file_id, created_at)
    SELECT id, TRUE, @file_id::BIGINT, @now::TIMESTAMP
    FROM activated
  )
SELECT
  (SELECT COUNT(*) FROM activated) AS activated_count,
  (SELECT COUNT(*) FROM deactivated) AS deactivated_count;

ಸಂಕೀರ್ಣವಾಗಿ ಕಾಣುವುದು ವಾಸ್ತವವಾಗಿ ಪ್ರತ್ಯೇಕ ಕ್ವೆರಿಗಳು ಮಾಡಿದ್ದನ್ನೇ ಮಾಡುತ್ತಿದೆ—ಆದರೆ ಎಲ್ಲವೂ ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗಿನ ಒಂದೇ ಸಂಭಾಷಣೆಯಲ್ಲಿ. CTE ತುಣುಕುಗಳನ್ನು ಒಂದಕ್ಕೊಂದು ಸರಪಳಿಯಂತೆ ಜೋಡಿಸುತ್ತದೆ: ಒಳಬರುವ ಡೇಟಾವು ಸಕ್ರಿಯಗೊಳಿಸುವ ಹಂತಕ್ಕೆ ತಲುಪುತ್ತದೆ, ಅದು ಹಿಸ್ಟರಿ ಹಂತಕ್ಕೆ ತಲುಪುತ್ತದೆ, ಮತ್ತು ಹೀಗೆ ಮುಂದುವರಿಯುತ್ತದೆ.

ವೇಗ ಹೆಚ್ಚಳ (Speedup)

ಫಲಿತಾಂಶಗಳು ತಾವೇ ಮಾತನಾಡುತ್ತವೆ:

• 10,000 ವಿಳಾಸಗಳು: ~5 ಸೆಕೆಂಡುಗಳು (ನಿಧಾನಗತಿಯ ಆವೃತ್ತಿ) → ~3 ಸೆಕೆಂಡುಗಳು (CTE)
• 100,000 ವಿಳಾಸಗಳು: ~90 ಸೆಕೆಂಡುಗಳು (ನಿಧಾನಗತಿಯ ಆವೃತ್ತಿ) → ~5 ಸೆಕೆಂಡುಗಳು (CTE)
• 1 ಮಿಲಿಯನ್ ವಿಳಾಸಗಳು: ~30 ಸೆಕೆಂಡುಗಳು (CTE)

ಇದು 100k ಪ್ರಕರಣಕ್ಕೆ 18 ಪಟ್ಟು ವೇಗ ಹೆಚ್ಚಳವಾಗಿದೆ, ಇದು ಕೇವಲ ಡೇಟಾ ಹರಿಯುವಿಕೆಯನ್ನು ಮರುರಚಿಸುವ ಮೂಲಕ ಸಾಧಿಸಲ್ಪಟ್ಟಿದೆ—ಡೇಟಾಬೇಸ್ ಹೆಚ್ಚು ಕಷ್ಟಪಟ್ಟು ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುವುದರಿಂದ ಅಲ್ಲ, ಬದಲಿಗೆ ಅದು ಹೆಚ್ಚು ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುವುದರಿಂದ.

ಇದು ಏಕೆ ಮುಖ್ಯ

ಇಲ್ಲಿನ ಪಾಠವು ಪ್ರಕೃತಿವಿರುದ್ಧವೆನಿಸಬಹುದು: ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ, ರೌಂಡ್-ಟ್ರಿಪ್ ವೆಚ್ಚವು (ಡೇಟಾವನ್ನು ಹಿಂದೆ ಮತ್ತು ಮುಂದೆ ಕಳುಹಿಸಲು ವ್ಯಯಿಸುವ ಸಮಯ) ಸಾಮಾನ್ಯವಾಗಿ ನೈಜ ಕಂಪ್ಯೂಟೇಶನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಐದು ಟ್ರಿಪ್‌ಗಳನ್ನು ಒಂದಾಗಿ ಕ್ರೋಡೀಕರಿಸುವ ಮೂಲಕ, Podorvanov ಕೇವಲ ಸಮಯವನ್ನು ಉಳಿಸಲಿಲ್ಲ—ಅವರು ಸರ್ವರ್ ಲೋಡ್ ಅನ್ನು ಸಹ ಕಡಿಮೆ ಮಾಡಿದರು ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹೆಚ್ಚು ಅಟಾಮಿಕ್ (atomic) ಮಾಡಿದರು (ಎಲ್ಲವೂ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಅಥವಾ ಯಾವುದೂ ಆಗುವುದಿಲ್ಲ, ನಡುವೆ ಯಾವುದೇ ಭಾಗಶಃ ಸ್ಥಿತಿಗಳಿರುವುದಿಲ್ಲ).

ಇದು ಮಾಟಮಂತ್ರವಲ್ಲ; ಇದು ಎಲ್ಲಿಯಾದರೂ ಅನ್ವಯಿಸುವ ತತ್ವವಾಗಿದೆ: ಅನಗತ್ಯವಾಗಿ ಮುಂದು-ಹಿಂದು ಹೋಗುವುದನ್ನು ಕನಿಷ್ಠಗೊಳಿಸಿ, ಮತ್ತು ಸಿಸ್ಟಮ್‌ಗಳು ವೇಗವಾಗುತ್ತವೆ. ಈ ತಂತ್ರವು ಇಮೇಲ್ ಸಿಂಕ್‌ಗಳು, ಬ್ಯಾಚ್ ಇಂಪೋರ್ಟ್‌ಗಳು ಅಥವಾ ಬಹು ರೀಡ್ ಮತ್ತು ರೈಟ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಜೋಡಿಸುವ ಯಾವುದೇ ಕಾರ್ಯಾಚರಣೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ತೀರ್ಮಾನ

ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಾಚರಣೆಯು ನಿಧಾನವೆನಿಸಿದಾಗ, ಅಪರಾಧಿ ಸಾಮಾನ್ಯವಾಗಿ ಕ್ವೆರಿಯೇ ಆಗಿರುವುದಿಲ್ಲ ಬದಲಿಗೆ ನೀವು ಎಷ್ಟು ಪ್ರತ್ಯೇಕ ಕ್ವೆರಿಗಳನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದಾಗಿದೆ. CTE ಗಳು ಅನೇಕ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಒಂದೇ ಅಟಾಮಿಕ್ ಹಂತವಾಗಿ ಸಂಯೋಜಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ನೀಡುತ್ತವೆ, ರೌಂಡ್-ಟ್ರಿಪ್ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಕಡಿತಗೊಳಿಸುತ್ತವೆ ಮತ್ತು ಥ್ರೂಪುಟ್ ಅನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸುಧಾರಿಸುತ್ತವೆ. ಇಮೇಲ್ ಸಿಂಕಿಂಗ್ ಅಥವಾ ಬ್ಯಾಚ್ ಅಪ್‌ಲೋಡ್‌ಗಳಂತಹ ವರ್ಕ್‌ಲೋಡ್‌ಗಳಿಗೆ, ಈ ರೀತಿಯ ಆಪ್ಟಿಮೈಸೇಶನ್ 90-ಸೆಕೆಂಡ್‌ಗಳ ಕಾರ್ಯಾಚರಣೆ ಮತ್ತು 5-ಸೆಕೆಂಡ್‌ಗಳ ಕಾರ್ಯಾಚರಣೆಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸವಾಗಬಹುದು.

ಅನುಕೂಲಗಳು (Merits)

• ಡೇಟಾಬೇಸ್ ರೌಂಡ್-ಟ್ರಿಪ್‌ಗಳನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಲ್ಯಾಟೆನ್ಸಿಯನ್ನು ಕಡಿತಗೊಳಿಸುತ್ತದೆ
• ಡೇಟಾ ಸ್ಥಿರತೆಯನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತದೆ—ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು ಒಂದೇ ಟ್ರಾನ್ಸಾಕ್ಷನ್‌ನಲ್ಲಿ ಅಟಾಮಿಕ್ ಆಗಿ ಸಂಭವಿಸುತ್ತವೆ
• ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ (ಕಡಿಮೆ ಪ್ರತ್ಯೇಕ ಫಂಕ್ಷನ್ ಕರೆಗಳು)
• ರೇಖೀಯವಾಗಿ (linearly) ಸ್ಕೇಲ್ ಆಗುತ್ತದೆ; ಅದೇ ಕ್ವೆರಿ 10k ಅಥವಾ 1M ವಿಳಾಸಗಳಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ
• ಡೇಟಾಬೇಸ್‌ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ವಿರೋಧಿಸುವ ಬದಲು ಅವುಗಳ ಸೌಲಭ್ಯವನ್ನು ಪಡೆಯುತ್ತದೆ

ಅನಾನುಕೂಲಗಳು (Demerits)

• CTE ಸಿಂಟ್ಯಾಕ್ಸ್ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ ಮತ್ತು ಡಿಬಗ್ ಮಾಡಲು ಕಷ್ಟವಾಗಬಹುದು
• ಸುಧಾರಿತ SQL ನ ಪರಿಚಯದ ಅಗತ್ಯವಿದೆ—ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಹೊಸಬರಾಗಿರುವ ತಂಡಗಳಿಗೆ ಇದು ಸೂಕ್ತವಲ್ಲ
• ಡೇಟಾಬೇಸ್ ಲಾಗ್‌ಗಳು ಕಡಿಮೆ ಕಣರೂಪದವುಗಳಾಗುತ್ತವೆ (ಯಾವ ಹಂತವು ನಿಧಾನವಾಗಿತ್ತು ಎಂದು ನಿಖರವಾಗಿ ನೋಡುವುದು ಕಷ್ಟ)
• ಎಲ್ಲಾ ಡೇಟಾಬೇಸ್‌ಗಳು CTE ಗಳನ್ನು ಸಮಾನವಾಗಿ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ
• ಓವರ್‌ಹೆಡ್ ವಿಷಯವಾಗದ ಸಣ್ಣ ಡೇಟಾಸೆಟ್‌ಗಳಿಗೆ ಇದು ಅತಿಯಾಗಬಹುದು (overkill)

ಎಚ್ಚರಿಕೆ

ಈ ಲೇಖನವು ಶೈಕ್ಷಣಿಕವಾಗಿದೆ ಮತ್ತು ನೈಜ-ಪ್ರಪಂಚದ ಉದಾಹರಣೆಯಿಂದ ಪಡೆಯಲಾಗಿದೆ. ಇದೇ ರೀತಿಯ ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ಯಾವುದೇ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಮೌಲ್ಯಗಳನ್ನು (ಅಂದರೆ @file_id ಅಥವಾ @now ನಂತಹವು) ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೂಲ ವೇರಿಯಬಲ್‌ಗಳಿಂದ ಬದಲಾಯಿಸಿ, ನಿಮ್ಮ ಸ್ವಂತ ಡೇಟಾ ಪರಿಮಾಣದೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಅವುಗಳನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು ಮೂಲ ಮೂಲದ ವಿರುದ್ಧ ಹಕ್ಕುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆಯು ಸನ್ನಿವೇಶದ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ; ಇಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದು ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಸ್ಕೀಮಾ, ಇಂಡೆಕ್ಸ್‌ಗಳು ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್‌ಗಾಗಿ ಟ್ಯೂನಿಂಗ್ ಅಗತ್ಯವಿರಬಹುದು.

ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

• PostgreSQL ನಲ್ಲಿ CTE ಎಂದರೇನು ಮತ್ತು ಅದು ಕ್ವೆರಿ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೇಗೆ ಸುಧಾರಿಸುತ್ತದೆ?
• ಇಮೇಲ್ ಸಿಂಕಿಂಗ್ ಹೊರತುಪಡಿಸಿ ಇತರ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ CTE ಗಳನ್ನು ಬಳಸಬಹುದೇ?
• ಏನಾದರೂ ತಪ್ಪಾದಾಗ CTE ಕ್ವೆರಿಯನ್ನು ನೀವು ಹೇಗೆ ಡಿಬಗ್ ಮಾಡುತ್ತೀರಿ?
• CTE ಮತ್ತು ಸ್ಟೋರ್ಡ್ ಪ್ರೊಸೀಜರ್ (stored procedure) ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇನು?
• ಎಲ್ಲಾ SQL ಡೇಟಾಬೇಸ್‌ಗಳು CTE ಗಳನ್ನು ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಬೆಂಬಲಿಸುತ್ತವೆಯೇ?
• ಪ್ರತ್ಯೇಕ ಕ್ವೆರಿಗಳನ್ನು ಮಾಡುವುದಕ್ಕೆ ಹೋಲಿಸಿದರೆ CTE ಸರಿಯಾದ ಸಾಧನವಾಗಿರುವುದು ಯಾವಾಗ?
• CTE ಗಳು ಇಂಡೆಕ್ಸ್ ಬಳಕೆ ಮತ್ತು ಕ್ವೆರಿ ಪ್ಲಾನಿಂಗ್ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ?
• CTE ಕಾರ್ಯಾಚರಣೆಯು ಮಧ್ಯದಲ್ಲಿ ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ?

ಟ್ಯಾಗ್‍ಗಳು

#postgres #database #performance #cte #sql #optimization #batch-processing #postgresql