PostgreSQL ಮತ್ತು JDBC ಎಲ್ಲಾ ರಸವನ್ನು ಹಿಂಡುತ್ತವೆ. ವ್ಲಾಡಿಮಿರ್ ಸಿಟ್ನಿಕೋವ್

ವ್ಲಾಡಿಮಿರ್ ಸಿಟ್ನಿಕೋವ್ ಅವರ 2016 ರ ಆರಂಭಿಕ ವರದಿಯ ಪ್ರತಿಲೇಖನವನ್ನು ಓದಲು ನಾನು ನಿಮಗೆ ಸಲಹೆ ನೀಡುತ್ತೇನೆ "PostgreSQL ಮತ್ತು JDBC ಎಲ್ಲಾ ರಸವನ್ನು ಹಿಂಡುತ್ತಿವೆ"

ಶುಭ ಅಪರಾಹ್ನ ನನ್ನ ಹೆಸರು ವ್ಲಾಡಿಮಿರ್ ಸಿಟ್ನಿಕೋವ್. ನಾನು ನೆಟ್‌ಕ್ರಾಕರ್‌ಗಾಗಿ 10 ವರ್ಷಗಳಿಂದ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ. ಮತ್ತು ನಾನು ಹೆಚ್ಚಾಗಿ ಉತ್ಪಾದಕತೆಯಲ್ಲಿದ್ದೇನೆ. ಜಾವಾಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲವೂ, SQL ಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲವೂ ನಾನು ಇಷ್ಟಪಡುತ್ತೇನೆ.

ಮತ್ತು ಇಂದು ನಾವು PostgreSQL ಅನ್ನು ಡೇಟಾಬೇಸ್ ಸರ್ವರ್ ಆಗಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ನಾವು ಕಂಪನಿಯಲ್ಲಿ ಏನು ಎದುರಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇನೆ. ಮತ್ತು ನಾವು ಹೆಚ್ಚಾಗಿ ಜಾವಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ. ಆದರೆ ಇಂದು ನಾನು ನಿಮಗೆ ಹೇಳಲು ಹೊರಟಿರುವುದು ಕೇವಲ ಜಾವಾ ಬಗ್ಗೆ ಅಲ್ಲ. ಅಭ್ಯಾಸವು ತೋರಿಸಿದಂತೆ, ಇದು ಇತರ ಭಾಷೆಗಳಲ್ಲಿಯೂ ಕಂಡುಬರುತ್ತದೆ.

ನಾವು ಮಾತನಾಡೋಣ:

• ಡೇಟಾ ಮಾದರಿಯ ಬಗ್ಗೆ.
• ಡೇಟಾವನ್ನು ಉಳಿಸುವ ಬಗ್ಗೆ.
• ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ.
• ಮತ್ತು ಅಲ್ಲಿ ಸಮಾಧಿಯಾಗಿರುವ ನೀರೊಳಗಿನ ಕುಂಟೆಗಳ ಬಗ್ಗೆ.

ಸರಳವಾದ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ನಾವು ಪ್ರಾಥಮಿಕ ಕೀಲಿಯನ್ನು ಆಧರಿಸಿ ಟೇಬಲ್‌ನಿಂದ ಒಂದು ಸಾಲನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ.

ಡೇಟಾಬೇಸ್ ಅದೇ ಹೋಸ್ಟ್ನಲ್ಲಿದೆ. ಮತ್ತು ಈ ಎಲ್ಲಾ ಕೃಷಿಯು 20 ಮಿಲಿಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಈ 20 ಮಿಲಿಸೆಕೆಂಡುಗಳು ಬಹಳಷ್ಟು. ನೀವು ಅಂತಹ 100 ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಈ ವಿನಂತಿಗಳ ಮೂಲಕ ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಮಯವನ್ನು ಸ್ಕ್ರೋಲ್ ಮಾಡುತ್ತೀರಿ, ಅಂದರೆ ನಾವು ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತಿದ್ದೇವೆ.

ನಾವು ಇದನ್ನು ಮಾಡಲು ಇಷ್ಟಪಡುವುದಿಲ್ಲ ಮತ್ತು ಇದಕ್ಕಾಗಿ ಬೇಸ್ ನಮಗೆ ಏನು ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ. ಪ್ರಶ್ನೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಡೇಟಾಬೇಸ್ ನಮಗೆ ಎರಡು ಆಯ್ಕೆಗಳನ್ನು ನೀಡುತ್ತದೆ.

ಮೊದಲ ಆಯ್ಕೆಯು ಸರಳ ವಿನಂತಿಯಾಗಿದೆ. ಅದರಲ್ಲಿ ಏನು ಒಳ್ಳೆಯದು? ನಾವು ಅದನ್ನು ತೆಗೆದುಕೊಂಡು ಕಳುಹಿಸುತ್ತೇವೆ ಮತ್ತು ಇನ್ನೇನೂ ಇಲ್ಲ.

https://github.com/pgjdbc/pgjdbc/pull/478

ಡೇಟಾಬೇಸ್ ಸುಧಾರಿತ ಪ್ರಶ್ನೆಯನ್ನು ಸಹ ಹೊಂದಿದೆ, ಇದು ಹೆಚ್ಚು ಟ್ರಿಕಿ, ಆದರೆ ಹೆಚ್ಚು ಕ್ರಿಯಾತ್ಮಕವಾಗಿದೆ. ಪಾರ್ಸಿಂಗ್, ಎಕ್ಸಿಕ್ಯೂಶನ್, ವೇರಿಯಬಲ್ ಬೈಂಡಿಂಗ್ ಇತ್ಯಾದಿಗಳಿಗಾಗಿ ನೀವು ಪ್ರತ್ಯೇಕವಾಗಿ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಬಹುದು.

ಸೂಪರ್ ವಿಸ್ತೃತ ಪ್ರಶ್ನೆಯು ಪ್ರಸ್ತುತ ವರದಿಯಲ್ಲಿ ನಾವು ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ. ನಾವು, ಬಹುಶಃ, ಡೇಟಾಬೇಸ್‌ನಿಂದ ಏನನ್ನಾದರೂ ಬಯಸುತ್ತೇವೆ ಮತ್ತು ಕೆಲವು ರೂಪದಲ್ಲಿ ರೂಪುಗೊಂಡ ಇಚ್ಛೆಯ ಪಟ್ಟಿ ಇದೆ, ಅಂದರೆ ಇದು ನಮಗೆ ಬೇಕಾಗಿರುವುದು, ಆದರೆ ಈಗ ಮತ್ತು ಮುಂದಿನ ವರ್ಷದಲ್ಲಿ ಇದು ಅಸಾಧ್ಯ. ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಮುಖ್ಯ ಜನರನ್ನು ಅಲ್ಲಾಡಿಸುತ್ತೇವೆ.

ಮತ್ತು ನಾವು ಏನು ಮಾಡಬಹುದು ಸರಳ ಪ್ರಶ್ನೆ ಮತ್ತು ವಿಸ್ತೃತ ಪ್ರಶ್ನೆ.

ಪ್ರತಿ ವಿಧಾನದ ವಿಶೇಷತೆ ಏನು?

ಒಂದು ಬಾರಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸರಳವಾದ ಪ್ರಶ್ನೆಯು ಒಳ್ಳೆಯದು. ಒಮ್ಮೆ ಮಾಡಿ ಮರೆತುಬಿಟ್ಟೆ. ಮತ್ತು ಸಮಸ್ಯೆಯೆಂದರೆ ಅದು ಬೈನರಿ ಡೇಟಾ ಸ್ವರೂಪವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಅಂದರೆ ಇದು ಕೆಲವು ಉನ್ನತ-ಕಾರ್ಯಕ್ಷಮತೆಯ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಸೂಕ್ತವಲ್ಲ.

ವಿಸ್ತೃತ ಪ್ರಶ್ನೆ - ಪಾರ್ಸಿಂಗ್‌ನಲ್ಲಿ ಸಮಯವನ್ನು ಉಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದನ್ನೇ ನಾವು ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಇದು ನಿಜವಾಗಿಯೂ ನಮಗೆ ಸಹಾಯ ಮಾಡಿದೆ. ಪಾರ್ಸಿಂಗ್‌ನಲ್ಲಿ ಮಾತ್ರ ಉಳಿತಾಯವಿಲ್ಲ. ಡೇಟಾ ವರ್ಗಾವಣೆಯಲ್ಲಿ ಉಳಿತಾಯವಿದೆ. ಬೈನರಿ ರೂಪದಲ್ಲಿ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸುವುದು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ.

ಅಭ್ಯಾಸಕ್ಕೆ ಹೋಗೋಣ. ಇದು ವಿಶಿಷ್ಟವಾದ ಅಪ್ಲಿಕೇಶನ್‌ನಂತೆ ಕಾಣುತ್ತದೆ. ಇದು ಜಾವಾ, ಇತ್ಯಾದಿ ಆಗಿರಬಹುದು.

ನಾವು ಹೇಳಿಕೆಯನ್ನು ರಚಿಸಿದ್ದೇವೆ. ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದೆ. ಹತ್ತಿರ ರಚಿಸಲಾಗಿದೆ. ಇಲ್ಲಿ ತಪ್ಪು ಎಲ್ಲಿದೆ? ಸಮಸ್ಯೆ ಏನು? ಯಾವ ತೊಂದರೆಯಿಲ್ಲ. ಎಲ್ಲ ಪುಸ್ತಕಗಳಲ್ಲೂ ಇದನ್ನೇ ಹೇಳಲಾಗಿದೆ. ಹೀಗೆ ಬರೆಯಬೇಕು. ನೀವು ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಬಯಸಿದರೆ, ಈ ರೀತಿ ಬರೆಯಿರಿ.

ಆದರೆ ಇದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಅಭ್ಯಾಸವು ತೋರಿಸಿದೆ. ಏಕೆ? ಏಕೆಂದರೆ ನಮ್ಮಲ್ಲಿ "ಹತ್ತಿರ" ವಿಧಾನವಿದೆ. ಮತ್ತು ನಾವು ಇದನ್ನು ಮಾಡಿದಾಗ, ಡೇಟಾಬೇಸ್ ದೃಷ್ಟಿಕೋನದಿಂದ ಇದು ಡೇಟಾಬೇಸ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಧೂಮಪಾನಿಯಂತೆ ಎಂದು ತಿರುಗುತ್ತದೆ. ನಾವು "ಪಾರ್ಸ್ ಎಕ್ಸಿಕ್ಯೂಟ್ ಡೀಲೋಕೇಟ್" ಎಂದು ಹೇಳಿದೆವು.

ಈ ಎಲ್ಲಾ ಹೆಚ್ಚುವರಿ ಸೃಷ್ಟಿ ಮತ್ತು ಹೇಳಿಕೆಗಳನ್ನು ಇಳಿಸುವುದು ಏಕೆ? ಯಾರಿಗೂ ಅವರ ಅಗತ್ಯವಿಲ್ಲ. ಆದರೆ PreparedStatements ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಏನಾಗುತ್ತದೆ ಎಂದರೆ ನಾವು ಅವುಗಳನ್ನು ಮುಚ್ಚಿದಾಗ ಅವು ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿರುವ ಎಲ್ಲವನ್ನೂ ಮುಚ್ಚುತ್ತವೆ. ಇದು ನಮಗೆ ಬೇಕಾಗಿಲ್ಲ.

ನಾವು ಆರೋಗ್ಯವಂತ ಜನರಂತೆ ಬೇಸ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ. ನಾವು ಒಮ್ಮೆ ನಮ್ಮ ಹೇಳಿಕೆಯನ್ನು ತೆಗೆದುಕೊಂಡು ಸಿದ್ಧಪಡಿಸಿದ್ದೇವೆ, ನಂತರ ನಾವು ಅದನ್ನು ಹಲವು ಬಾರಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ. ವಾಸ್ತವವಾಗಿ, ಹಲವು ಬಾರಿ - ಇದು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಸಂಪೂರ್ಣ ಜೀವನದಲ್ಲಿ ಒಮ್ಮೆ - ಅವುಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಲಾಗಿದೆ. ಮತ್ತು ನಾವು ವಿಭಿನ್ನ REST ಗಳಲ್ಲಿ ಒಂದೇ ಹೇಳಿಕೆ ಐಡಿಯನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು ನಮ್ಮ ಗುರಿಯಾಗಿದೆ.

ನಾವು ಇದನ್ನು ಹೇಗೆ ಸಾಧಿಸಬಹುದು?

ಇದು ತುಂಬಾ ಸರಳವಾಗಿದೆ - ಹೇಳಿಕೆಗಳನ್ನು ಮುಚ್ಚುವ ಅಗತ್ಯವಿಲ್ಲ. ನಾವು ಇದನ್ನು ಈ ರೀತಿ ಬರೆಯುತ್ತೇವೆ: "ತಯಾರಿಸು" "ಕಾರ್ಯಗತಗೊಳಿಸಿ".

ನಾವು ಈ ರೀತಿಯದನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ, ಎಲ್ಲೋ ಏನೋ ಉಕ್ಕಿ ಹರಿಯುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ. ಇದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು. ಈ ಸರಳ ವಿಧಾನವನ್ನು ಬಳಸುವ ಮಾನದಂಡವನ್ನು ಬರೆಯೋಣ. ಹೇಳಿಕೆಯನ್ನು ರಚಿಸಿ. ನಾವು ಅದನ್ನು ಡ್ರೈವರ್‌ನ ಕೆಲವು ಆವೃತ್ತಿಯಲ್ಲಿ ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಮತ್ತು ಅದು ಹೊಂದಿದ್ದ ಎಲ್ಲಾ ಮೆಮೊರಿಯ ನಷ್ಟದೊಂದಿಗೆ ಅದು ಬೇಗನೆ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಎಂದು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ.

ಅಂತಹ ದೋಷಗಳನ್ನು ಸುಲಭವಾಗಿ ಸರಿಪಡಿಸಬಹುದು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ನಾನು ಅವರ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ. ಆದರೆ ಹೊಸ ಆವೃತ್ತಿಯು ಹೆಚ್ಚು ವೇಗವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ. ವಿಧಾನವು ಮೂರ್ಖತನವಾಗಿದೆ, ಆದರೆ ಇನ್ನೂ.

ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದು ಹೇಗೆ? ಇದಕ್ಕಾಗಿ ನಾವು ಏನು ಮಾಡಬೇಕು?

ವಾಸ್ತವದಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಯಾವಾಗಲೂ ಹೇಳಿಕೆಗಳನ್ನು ಮುಚ್ಚುತ್ತವೆ. ಎಲ್ಲಾ ಪುಸ್ತಕಗಳಲ್ಲಿ ಅವರು ಅದನ್ನು ಮುಚ್ಚಲು ಹೇಳುತ್ತಾರೆ, ಇಲ್ಲದಿದ್ದರೆ ಮೆಮೊರಿ ಸೋರಿಕೆಯಾಗುತ್ತದೆ.

ಮತ್ತು PostgreSQL ಗೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸುವುದು ಎಂದು ತಿಳಿದಿಲ್ಲ. ಪ್ರತಿ ಅಧಿವೇಶನವು ಸ್ವತಃ ಈ ಸಂಗ್ರಹವನ್ನು ರಚಿಸುವುದು ಅವಶ್ಯಕ.

ಮತ್ತು ನಾವು ಪಾರ್ಸಿಂಗ್‌ನಲ್ಲಿ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ.

ಮತ್ತು ಎಂದಿನಂತೆ ನಮಗೆ ಎರಡು ಆಯ್ಕೆಗಳಿವೆ.

ಮೊದಲ ಆಯ್ಕೆಯು ನಾವು ಅದನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲವನ್ನೂ PgSQL ನಲ್ಲಿ ಸುತ್ತಿಕೊಳ್ಳೋಣ ಎಂದು ಹೇಳುತ್ತೇವೆ. ಅಲ್ಲಿ ಸಂಗ್ರಹವಿದೆ. ಇದು ಎಲ್ಲವನ್ನೂ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಇದು ಉತ್ತಮವಾಗಿ ಹೊರಹೊಮ್ಮುತ್ತದೆ. ನಾವು ಇದನ್ನು ನೋಡಿದ್ದೇವೆ. ನಾವು 100500 ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ವಿನಂತಿಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಾರ್ಯವಿಧಾನಗಳಾಗಿ ಪರಿವರ್ತಿಸಲು ನಾವು ಒಪ್ಪುವುದಿಲ್ಲ. ಇಲ್ಲ ಇಲ್ಲ.

ನಮಗೆ ಎರಡನೇ ಆಯ್ಕೆ ಇದೆ - ಅದನ್ನು ತೆಗೆದುಕೊಂಡು ಅದನ್ನು ನಾವೇ ಕತ್ತರಿಸಿ. ನಾವು ಮೂಲಗಳನ್ನು ತೆರೆಯುತ್ತೇವೆ ಮತ್ತು ಕತ್ತರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ನಾವು ನೋಡಿದ್ದೇವೆ ಮತ್ತು ನೋಡಿದ್ದೇವೆ. ಅದನ್ನು ಮಾಡಲು ತುಂಬಾ ಕಷ್ಟವಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು.

https://github.com/pgjdbc/pgjdbc/pull/319

ಇದು ಆಗಸ್ಟ್ 2015 ರಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿತು. ಈಗ ಹೆಚ್ಚು ಆಧುನಿಕ ಆವೃತ್ತಿ ಇದೆ. ಮತ್ತು ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ. ಇದು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದರೆ ನಾವು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಏನನ್ನೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಮತ್ತು ನಾವು PgSQL ನ ದಿಕ್ಕಿನಲ್ಲಿ ಯೋಚಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ್ದೇವೆ, ಅಂದರೆ ಎಲ್ಲಾ ಓವರ್‌ಹೆಡ್ ವೆಚ್ಚಗಳನ್ನು ಬಹುತೇಕ ಶೂನ್ಯಕ್ಕೆ ಇಳಿಸಲು ಇದು ನಮಗೆ ಸಾಕಷ್ಟು ಸಾಕಾಗಿತ್ತು.

ಅಂತೆಯೇ, ಪ್ರತಿ ಒಂದು ಬಾರಿ ವಿನಂತಿಯಲ್ಲಿ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಮೆಮೊರಿ ವ್ಯರ್ಥವಾಗುವುದನ್ನು ತಪ್ಪಿಸಲು ಸರ್ವರ್-ತಯಾರಾದ ಹೇಳಿಕೆಗಳನ್ನು 5 ನೇ ಎಕ್ಸಿಕ್ಯೂಶನ್‌ನಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ.

ನೀವು ಕೇಳಬಹುದು - ಸಂಖ್ಯೆಗಳು ಎಲ್ಲಿವೆ? ನೀವು ಏನು ಪಡೆಯುತ್ತಿದ್ದೀರಿ? ಮತ್ತು ಇಲ್ಲಿ ನಾನು ಸಂಖ್ಯೆಗಳನ್ನು ನೀಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ರತಿ ವಿನಂತಿಯು ತನ್ನದೇ ಆದದ್ದಾಗಿದೆ.

ನಮ್ಮ ಪ್ರಶ್ನೆಗಳು ಹೇಗಿದ್ದವು ಎಂದರೆ ನಾವು OLTP ಪ್ರಶ್ನೆಗಳನ್ನು ಪಾರ್ಸಿಂಗ್ ಮಾಡಲು ಸುಮಾರು 20 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು ವ್ಯಯಿಸಿದ್ದೇವೆ. ಮರಣದಂಡನೆಗೆ 0,5 ಮಿಲಿಸೆಕೆಂಡುಗಳು, ಪಾರ್ಸಿಂಗ್ಗಾಗಿ 20 ಮಿಲಿಸೆಕೆಂಡುಗಳು ಇದ್ದವು. ವಿನಂತಿ - 10 ಕಿಬಿ ಪಠ್ಯ, 170 ಸಾಲುಗಳ ಯೋಜನೆ. ಇದು OLTP ವಿನಂತಿಯಾಗಿದೆ. ಇದು 1, 5, 10 ಸಾಲುಗಳನ್ನು ವಿನಂತಿಸುತ್ತದೆ, ಕೆಲವೊಮ್ಮೆ ಹೆಚ್ಚು.

ಆದರೆ ನಾವು 20 ಮಿಲಿಸೆಕೆಂಡುಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡಲು ಬಯಸಲಿಲ್ಲ. ನಾವು ಅದನ್ನು 0 ಕ್ಕೆ ಇಳಿಸಿದ್ದೇವೆ. ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ.

ನೀವು ಇಲ್ಲಿಂದ ಏನು ತೆಗೆದುಕೊಂಡು ಹೋಗಬಹುದು? ನೀವು ಜಾವಾ ಹೊಂದಿದ್ದರೆ, ನಂತರ ನೀವು ಚಾಲಕನ ಆಧುನಿಕ ಆವೃತ್ತಿಯನ್ನು ತೆಗೆದುಕೊಂಡು ಹಿಗ್ಗು.

ನೀವು ಬೇರೆ ಭಾಷೆಯಲ್ಲಿ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಯೋಚಿಸಿ - ಬಹುಶಃ ನಿಮಗೆ ಇದು ಅಗತ್ಯವಿದೆಯೇ? ಏಕೆಂದರೆ ಅಂತಿಮ ಭಾಷೆಯ ದೃಷ್ಟಿಕೋನದಿಂದ, ಉದಾಹರಣೆಗೆ, PL 8 ಅಥವಾ ನೀವು LibPQ ಹೊಂದಿದ್ದರೆ, ನೀವು ಸಮಯವನ್ನು ಕಳೆಯುವುದು ಮರಣದಂಡನೆ, ಪಾರ್ಸಿಂಗ್‌ನಲ್ಲಿ ಅಲ್ಲ ಎಂಬುದು ನಿಮಗೆ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ ಮತ್ತು ಇದನ್ನು ಪರಿಶೀಲಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಹೇಗೆ? ಎಲ್ಲವೂ ಉಚಿತ.

ದೋಷಗಳು ಮತ್ತು ಕೆಲವು ವಿಶಿಷ್ಟತೆಗಳಿವೆ ಎಂದು ಹೊರತುಪಡಿಸಿ. ಮತ್ತು ನಾವು ಈಗ ಅವರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. ಅದರಲ್ಲಿ ಹೆಚ್ಚಿನವು ಕೈಗಾರಿಕಾ ಪುರಾತತ್ತ್ವ ಶಾಸ್ತ್ರದ ಬಗ್ಗೆ, ನಾವು ಕಂಡುಕೊಂಡ ವಿಷಯಗಳ ಬಗ್ಗೆ, ನಾವು ಕಂಡವುಗಳ ಬಗ್ಗೆ ಇರುತ್ತದೆ.

ವಿನಂತಿಯನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ರಚಿಸಿದರೆ. ಹಾಗೆ ಆಗುತ್ತದೆ. ಯಾರೋ ಒಬ್ಬರು ತಂತಿಗಳನ್ನು ಒಟ್ಟಿಗೆ ಅಂಟಿಸುತ್ತಾರೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ SQL ಪ್ರಶ್ನೆ ಉಂಟಾಗುತ್ತದೆ.

ಅವನು ಯಾಕೆ ಕೆಟ್ಟವನು? ಇದು ಕೆಟ್ಟದು ಏಕೆಂದರೆ ಪ್ರತಿ ಬಾರಿಯೂ ನಾವು ವಿಭಿನ್ನ ಸ್ಟ್ರಿಂಗ್‌ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೇವೆ.

ಮತ್ತು ಈ ವಿಭಿನ್ನ ಸ್ಟ್ರಿಂಗ್‌ನ ಹ್ಯಾಶ್‌ಕೋಡ್ ಅನ್ನು ಮತ್ತೆ ಓದಬೇಕಾಗಿದೆ. ಇದು ನಿಜವಾಗಿಯೂ CPU ಕಾರ್ಯವಾಗಿದೆ - ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಹ್ಯಾಶ್‌ನಲ್ಲಿ ದೀರ್ಘ ವಿನಂತಿಯ ಪಠ್ಯವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ. ಆದ್ದರಿಂದ, ತೀರ್ಮಾನವು ಸರಳವಾಗಿದೆ - ವಿನಂತಿಗಳನ್ನು ರಚಿಸಬೇಡಿ. ಅವುಗಳನ್ನು ಒಂದು ವೇರಿಯೇಬಲ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. ಮತ್ತು ಹಿಗ್ಗು.

ಮುಂದಿನ ಸಮಸ್ಯೆ. ಡೇಟಾ ಪ್ರಕಾರಗಳು ಮುಖ್ಯವಾಗಿವೆ. ಯಾವ ರೀತಿಯ NULL ಇದೆ ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ, ಕೆಲವು ರೀತಿಯ ಇರಲಿ ಎಂದು ಹೇಳುವ ORM ಗಳಿವೆ. ಇಂಟ್ ಆಗಿದ್ದರೆ, ನಾವು ಸೆಟ್‌ಇಂಟ್ ಎಂದು ಹೇಳುತ್ತೇವೆ. ಮತ್ತು NULL ಆಗಿದ್ದರೆ, ಅದು ಯಾವಾಗಲೂ VARCHAR ಆಗಿರಲಿ. ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಏನು ವ್ಯತ್ಯಾಸವನ್ನು ಮಾಡುತ್ತದೆ NULL ಅಲ್ಲಿ ಏನು? ಡೇಟಾಬೇಸ್ ಸ್ವತಃ ಎಲ್ಲವನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತು ಈ ಚಿತ್ರವು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಡೇಟಾಬೇಸ್ ಎಲ್ಲಾ ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ. ಇದು ಒಂದು ಸಂಖ್ಯೆ ಎಂದು ನೀವು ಮೊದಲ ಬಾರಿಗೆ ಹೇಳಿದರೆ ಮತ್ತು ಎರಡನೇ ಬಾರಿಗೆ ಇದು VARCHAR ಎಂದು ಹೇಳಿದರೆ, ನಂತರ ಸರ್ವರ್-ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡುವುದು ಅಸಾಧ್ಯ. ಮತ್ತು ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ನಮ್ಮ ಹೇಳಿಕೆಯನ್ನು ಪುನಃ ರಚಿಸಬೇಕಾಗಿದೆ.

ನೀವು ಅದೇ ಪ್ರಶ್ನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಕಾಲಮ್‌ನಲ್ಲಿರುವ ಡೇಟಾ ಪ್ರಕಾರಗಳು ಗೊಂದಲಕ್ಕೀಡಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ನೀವು NULL ಗಾಗಿ ಗಮನಹರಿಸಬೇಕು. ನಾವು PreparedStatements ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ ನಾವು ಹೊಂದಿರುವ ಸಾಮಾನ್ಯ ದೋಷ ಇದು

ಸರಿ, ಆನ್ ಮಾಡಲಾಗಿದೆ. ಬಹುಶಃ ಅವರು ಚಾಲಕನನ್ನು ಕರೆದೊಯ್ದಿದ್ದಾರೆ. ಮತ್ತು ಉತ್ಪಾದಕತೆ ಕುಸಿಯಿತು. ವಿಷಯಗಳು ಕೆಟ್ಟವು.

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

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

ವಿಷಯವೆಂದರೆ ನಾವು ಎರಡು ಕಾಲಮ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಪ್ರತಿಯೊಂದೂ ಸೂಚ್ಯಂಕದಲ್ಲಿದೆ. ಒಂದು NULL ಕಾಲಮ್‌ನಲ್ಲಿ ಮಿಲಿಯನ್ ಸಾಲುಗಳಿವೆ. ಮತ್ತು ಎರಡನೇ ಕಾಲಮ್ ಕೇವಲ 20 ಸಾಲುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ನಾವು ಬೌಂಡ್ ಅಸ್ಥಿರಗಳಿಲ್ಲದೆ ಕಾರ್ಯಗತಗೊಳಿಸಿದಾಗ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ನಾವು ಬೌಂಡ್ ವೇರಿಯಬಲ್‌ಗಳೊಂದಿಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ಅಂದರೆ ನಾವು "?" ಅಥವಾ ನಮ್ಮ ವಿನಂತಿಗಾಗಿ "$1", ನಾವು ಏನನ್ನು ಪಡೆಯುತ್ತೇವೆ?

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

ಮೊದಲ ಮರಣದಂಡನೆ ನಿರೀಕ್ಷೆಯಂತೆ ಆಗಿದೆ. ಎರಡನೆಯದು ಸ್ವಲ್ಪ ವೇಗವಾಗಿರುತ್ತದೆ. ಏನೋ ಕ್ಯಾಶ್ ಆಗಿತ್ತು. ಮೂರನೇ, ನಾಲ್ಕನೇ, ಐದನೇ. ನಂತರ ಬ್ಯಾಂಗ್ - ಮತ್ತು ಹಾಗೆ. ಮತ್ತು ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ ಇದು ಆರನೇ ಮರಣದಂಡನೆಯಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ. ನಿಜವಾದ ಮರಣದಂಡನೆ ಯೋಜನೆ ಏನೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಖರವಾಗಿ ಆರು ಮರಣದಂಡನೆಗಳನ್ನು ಮಾಡುವುದು ಅಗತ್ಯವೆಂದು ಯಾರು ತಿಳಿದಿದ್ದರು?

ತಪ್ಪಿತಸ್ಥರು ಯಾರು? ಏನಾಯಿತು? ಡೇಟಾಬೇಸ್ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಮತ್ತು ಇದು ಸಾಮಾನ್ಯ ಪ್ರಕರಣಕ್ಕೆ ಹೊಂದುವಂತೆ ತೋರುತ್ತದೆ. ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ಕೆಲವು ಹಂತದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಅವಳು ಸಾಮಾನ್ಯ ಯೋಜನೆಗೆ ಬದಲಾಯಿಸುತ್ತಾಳೆ, ಅದು ದುರದೃಷ್ಟವಶಾತ್, ವಿಭಿನ್ನವಾಗಿರಬಹುದು. ಇದು ಒಂದೇ ಆಗಿರಬಹುದು, ಅಥವಾ ಅದು ವಿಭಿನ್ನವಾಗಿರಬಹುದು. ಮತ್ತು ಈ ನಡವಳಿಕೆಗೆ ಕಾರಣವಾಗುವ ಕೆಲವು ರೀತಿಯ ಮಿತಿ ಮೌಲ್ಯವಿದೆ.

ನೀವು ಅದರ ಬಗ್ಗೆ ಏನು ಮಾಡಬಹುದು? ಇಲ್ಲಿ, ಸಹಜವಾಗಿ, ಯಾವುದನ್ನಾದರೂ ಊಹಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟ. ನಾವು ಬಳಸುವ ಸರಳ ಪರಿಹಾರವಿದೆ. ಇದು +0, OFFSET 0. ಖಂಡಿತವಾಗಿಯೂ ನಿಮಗೆ ಅಂತಹ ಪರಿಹಾರಗಳು ತಿಳಿದಿವೆ. ನಾವು ಅದನ್ನು ತೆಗೆದುಕೊಂಡು ವಿನಂತಿಗೆ "+0" ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ ಮತ್ತು ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ನಾನು ನಿಮಗೆ ನಂತರ ತೋರಿಸುತ್ತೇನೆ.

ಮತ್ತು ಇನ್ನೊಂದು ಆಯ್ಕೆ ಇದೆ - ಯೋಜನೆಗಳನ್ನು ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯಿಂದ ನೋಡಿ. ಡೆವಲಪರ್ ವಿನಂತಿಯನ್ನು ಮಾತ್ರ ಬರೆಯಬಾರದು, ಆದರೆ "ವಿವರಿಸಿ ವಿಶ್ಲೇಷಿಸಿ" ಎಂದು 6 ಬಾರಿ ಹೇಳಬೇಕು. ಇದು 5 ಆಗಿದ್ದರೆ, ಅದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ.

ಮತ್ತು ಮೂರನೇ ಆಯ್ಕೆ ಇದೆ - pgsql-ಹ್ಯಾಕರ್‌ಗಳಿಗೆ ಪತ್ರ ಬರೆಯಿರಿ. ನಾನು ಬರೆದಿದ್ದೇನೆ, ಆದಾಗ್ಯೂ, ಇದು ದೋಷವೇ ಅಥವಾ ವೈಶಿಷ್ಟ್ಯವೇ ಎಂಬುದು ಇನ್ನೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

ಇದು ದೋಷವೇ ಅಥವಾ ವೈಶಿಷ್ಟ್ಯವೇ ಎಂದು ನಾವು ಯೋಚಿಸುತ್ತಿರುವಾಗ, ಅದನ್ನು ಸರಿಪಡಿಸೋಣ. ನಮ್ಮ ವಿನಂತಿಯನ್ನು ತೆಗೆದುಕೊಂಡು "+0" ಅನ್ನು ಸೇರಿಸೋಣ. ಎಲ್ಲವು ಚೆನ್ನಾಗಿದೆ. ಎರಡು ಚಿಹ್ನೆಗಳು ಮತ್ತು ಅದು ಹೇಗೆ ಅಥವಾ ಅದು ಏನು ಎಂದು ನೀವು ಯೋಚಿಸಬೇಕಾಗಿಲ್ಲ. ತುಂಬಾ ಸರಳ. ಈ ಕಾಲಮ್‌ನಲ್ಲಿ ಸೂಚ್ಯಂಕವನ್ನು ಬಳಸದಂತೆ ನಾವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸರಳವಾಗಿ ನಿಷೇಧಿಸಿದ್ದೇವೆ. "+0" ಕಾಲಮ್ನಲ್ಲಿ ನಾವು ಸೂಚ್ಯಂಕವನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಅದು ಇಲ್ಲಿದೆ, ಡೇಟಾಬೇಸ್ ಸೂಚ್ಯಂಕವನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ.

ಇದು 6 ರ ನಿಯಮವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಈಗ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಗಳಲ್ಲಿ ನೀವು ಬೌಂಡ್ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ನೀವು ಇದನ್ನು 6 ಬಾರಿ ಮಾಡಬೇಕು. ನೀವು ಬೌಂಡ್ ಅಸ್ಥಿರಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ನಾವು ಏನು ಮಾಡುತ್ತೇವೆ. ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಇದು ನಿಖರವಾಗಿ ಈ ವಿನಂತಿಯು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ. ಇದು ಟ್ರಿಕಿ ವಿಷಯ ಅಲ್ಲ.

ಇದು ತೋರುತ್ತದೆ, ಎಷ್ಟು ಸಾಧ್ಯ? ಇಲ್ಲಿ ಒಂದು ದೋಷ, ಅಲ್ಲಿ ಒಂದು ದೋಷ. ವಾಸ್ತವವಾಗಿ, ದೋಷವು ಎಲ್ಲೆಡೆ ಇದೆ.

ಹತ್ತಿರದಿಂದ ನೋಡೋಣ. ಉದಾಹರಣೆಗೆ, ನಾವು ಎರಡು ಸ್ಕೀಮಾಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಟೇಬಲ್ S ಜೊತೆಗೆ ಸ್ಕೀಮ್ A ಮತ್ತು ಟೇಬಲ್ S ಜೊತೆಗೆ ರೇಖಾಚಿತ್ರ B. ಪ್ರಶ್ನೆ - ಟೇಬಲ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಮಗೆ ಏನು ಇರುತ್ತದೆ? ನಾವು ದೋಷವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಮೇಲಿನ ಎಲ್ಲವನ್ನೂ ಹೊಂದಿದ್ದೇವೆ. ನಿಯಮವೆಂದರೆ - ಒಂದು ದೋಷವು ಎಲ್ಲೆಡೆ ಇದೆ, ನಾವು ಮೇಲಿನ ಎಲ್ಲವನ್ನೂ ಹೊಂದಿದ್ದೇವೆ.

ಈಗ ಪ್ರಶ್ನೆ: "ಏಕೆ?" ನಾವು ಸ್ಕೀಮಾವನ್ನು ಹೊಂದಿದ್ದರೆ, ಟೇಬಲ್ ಅನ್ನು ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದು ನಮಗೆ ತಿಳಿಸುವ "ಹುಡುಕಾಟ_ಪಥ" ವೇರಿಯೇಬಲ್ ಇದೆ ಎಂದು ದಾಖಲಾತಿ ಇದೆ ಎಂದು ತೋರುತ್ತದೆ. ವೇರಿಯಬಲ್ ಇದೆ ಎಂದು ತೋರುತ್ತದೆ.

ಸಮಸ್ಯೆ ಏನು? ಸಮಸ್ಯೆಯೆಂದರೆ ಸರ್ವರ್-ತಯಾರಿಸಿದ ಹೇಳಿಕೆಗಳು ಹುಡುಕಾಟ_ಪಥವನ್ನು ಯಾರಾದರೂ ಬದಲಾಯಿಸಬಹುದೆಂದು ಅನುಮಾನಿಸುವುದಿಲ್ಲ. ಈ ಮೌಲ್ಯವು ಡೇಟಾಬೇಸ್‌ಗೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ. ಮತ್ತು ಕೆಲವು ಭಾಗಗಳು ಹೊಸ ಅರ್ಥಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳದಿರಬಹುದು.

ಸಹಜವಾಗಿ, ಇದು ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ಆವೃತ್ತಿಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ನಿಮ್ಮ ಕೋಷ್ಟಕಗಳು ಎಷ್ಟು ಗಂಭೀರವಾಗಿ ಭಿನ್ನವಾಗಿವೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಮತ್ತು ಆವೃತ್ತಿ 9.1 ಹಳೆಯ ವಿನಂತಿಗಳನ್ನು ಸರಳವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಹೊಸ ಆವೃತ್ತಿಗಳು ದೋಷವನ್ನು ಹಿಡಿಯಬಹುದು ಮತ್ತು ನೀವು ದೋಷವನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಹೇಳಬಹುದು.

search_path + ಸರ್ವರ್ ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆಗಳನ್ನು ಹೊಂದಿಸಿ =
ಕ್ಯಾಶ್ ಮಾಡಿದ ಯೋಜನೆಯು ಫಲಿತಾಂಶದ ಪ್ರಕಾರವನ್ನು ಬದಲಾಯಿಸಬಾರದು

ಚಿಕಿತ್ಸೆ ಹೇಗೆ? ಸರಳವಾದ ಪಾಕವಿಧಾನವಿದೆ - ಅದನ್ನು ಮಾಡಬೇಡಿ. ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಹುಡುಕಾಟ_ಪಥವನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಬದಲಾಯಿಸಿದರೆ, ಹೊಸ ಸಂಪರ್ಕವನ್ನು ರಚಿಸುವುದು ಉತ್ತಮ.

ನೀವು ಚರ್ಚಿಸಬಹುದು, ಅಂದರೆ ತೆರೆಯಿರಿ, ಚರ್ಚಿಸಿ, ಸೇರಿಸಿ. ಬಹುಶಃ ನಾವು ಡೇಟಾಬೇಸ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಮನವರಿಕೆ ಮಾಡಬಹುದು, ಯಾರಾದರೂ ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಡೇಟಾಬೇಸ್ ಕ್ಲೈಂಟ್‌ಗೆ ಈ ಬಗ್ಗೆ ಹೇಳಬೇಕು: “ನೋಡಿ, ನಿಮ್ಮ ಮೌಲ್ಯವನ್ನು ಇಲ್ಲಿ ನವೀಕರಿಸಲಾಗಿದೆ. ಬಹುಶಃ ನೀವು ಹೇಳಿಕೆಗಳನ್ನು ಮರುಹೊಂದಿಸಿ ಅವುಗಳನ್ನು ಮರುಸೃಷ್ಟಿಸಬೇಕೇ? ಈಗ ಡೇಟಾಬೇಸ್ ರಹಸ್ಯವಾಗಿ ವರ್ತಿಸುತ್ತದೆ ಮತ್ತು ಹೇಳಿಕೆಗಳು ಎಲ್ಲೋ ಒಳಗೆ ಬದಲಾಗಿದೆ ಎಂದು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ವರದಿ ಮಾಡುವುದಿಲ್ಲ.

ಮತ್ತು ನಾನು ಮತ್ತೊಮ್ಮೆ ಒತ್ತಿಹೇಳುತ್ತೇನೆ - ಇದು ಜಾವಾಗೆ ವಿಶಿಷ್ಟವಲ್ಲದ ಸಂಗತಿಯಾಗಿದೆ. ನಾವು PL/pgSQL ಒಂದರಿಂದ ಒಂದರಲ್ಲಿ ಒಂದೇ ವಿಷಯವನ್ನು ನೋಡುತ್ತೇವೆ. ಆದರೆ ಅದನ್ನು ಅಲ್ಲಿ ಪುನರುತ್ಪಾದಿಸಲಾಗುತ್ತದೆ.

ಇನ್ನೂ ಕೆಲವು ಡೇಟಾ ಆಯ್ಕೆಯನ್ನು ಪ್ರಯತ್ನಿಸೋಣ. ನಾವು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ. ನಾವು ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಹೊಂದಿರುವ ಟೇಬಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಪ್ರತಿ ಸಾಲು ಒಂದು ಕಿಲೋಬೈಟ್ ಆಗಿದೆ. ಅಂದಾಜು ಗಿಗಾಬೈಟ್ ಡೇಟಾ. ಮತ್ತು ನಾವು 128 ಮೆಗಾಬೈಟ್‌ಗಳ ಜಾವಾ ಯಂತ್ರದಲ್ಲಿ ಕೆಲಸದ ಸ್ಮರಣೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ನಾವು, ಎಲ್ಲಾ ಪುಸ್ತಕಗಳಲ್ಲಿ ಶಿಫಾರಸು ಮಾಡಿದಂತೆ, ಸ್ಟ್ರೀಮ್ ಸಂಸ್ಕರಣೆಯನ್ನು ಬಳಸುತ್ತೇವೆ. ಅಂದರೆ, ನಾವು ಫಲಿತಾಂಶ ಸೆಟ್ ಅನ್ನು ತೆರೆಯುತ್ತೇವೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಡೇಟಾವನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಓದುತ್ತೇವೆ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ? ಅದು ನೆನಪಿನಿಂದ ಬೀಳುತ್ತದೆಯೇ? ನೀವು ಸ್ವಲ್ಪ ಓದುತ್ತೀರಾ? ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ನಂಬಿಕೆ ಇಡೋಣ, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್‌ನಲ್ಲಿ ನಂಬಿಕೆ ಇಡೋಣ. ನಾವು ಅದನ್ನು ನಂಬುವುದಿಲ್ಲ. ನಾವು OutOFMemory ಬೀಳುತ್ತೇವೆಯೇ? OutOfMemory ಅನ್ನು ಯಾರು ಅನುಭವಿಸಿದ್ದಾರೆ? ಅದರ ನಂತರ ಅದನ್ನು ಸರಿಪಡಿಸಲು ಯಾರು ಯಶಸ್ವಿಯಾದರು? ಯಾರೋ ಅದನ್ನು ಸರಿಪಡಿಸುವಲ್ಲಿ ಯಶಸ್ವಿಯಾದರು.

ನೀವು ಮಿಲಿಯನ್ ಸಾಲುಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ನೀವು ಕೇವಲ ಆಯ್ಕೆ ಮಾಡಲು ಮತ್ತು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. OFFSET/LIMIT ಅಗತ್ಯವಿದೆ. ಈ ಆಯ್ಕೆಗೆ ಯಾರು? ಮತ್ತು ಸ್ವಯಂ ಕಮಿಟ್‌ನೊಂದಿಗೆ ಆಡುವ ಪರವಾಗಿ ಯಾರು?

ಇಲ್ಲಿ, ಎಂದಿನಂತೆ, ಅತ್ಯಂತ ಅನಿರೀಕ್ಷಿತ ಆಯ್ಕೆಯು ಸರಿಯಾಗಿದೆ. ಮತ್ತು ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಸ್ವಯಂಕಮಿಟ್ ಅನ್ನು ಆಫ್ ಮಾಡಿದರೆ, ಅದು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಅದು ಏಕೆ? ವಿಜ್ಞಾನಕ್ಕೆ ಇದರ ಬಗ್ಗೆ ತಿಳಿದಿಲ್ಲ.

ಆದರೆ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಡೇಟಾಬೇಸ್‌ಗೆ ಸಂಪರ್ಕಿಸುವ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳು ಸಂಪೂರ್ಣ ಡೇಟಾವನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತಾರೆ. ಈ ವಿಷಯದಲ್ಲಿ PgJDBC ಇದಕ್ಕೆ ಹೊರತಾಗಿಲ್ಲ; ಇದು ಎಲ್ಲಾ ಸಾಲುಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.

FetchSize ಥೀಮ್‌ನಲ್ಲಿ ವ್ಯತ್ಯಾಸವಿದೆ, ಅಂದರೆ ಇಲ್ಲಿ, ದಯವಿಟ್ಟು 10, 50 ರಿಂದ ಡೇಟಾವನ್ನು ಆಯ್ಕೆಮಾಡಿ ಎಂದು ಪ್ರತ್ಯೇಕ ಹೇಳಿಕೆಯ ಮಟ್ಟದಲ್ಲಿ ನೀವು ಹೇಳಬಹುದು. ಆದರೆ ನೀವು ಸ್ವಯಂಕಮಿಟ್ ಅನ್ನು ಆಫ್ ಮಾಡುವವರೆಗೆ ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಆಟೋಕಮಿಟ್ ಅನ್ನು ಆಫ್ ಮಾಡಲಾಗಿದೆ - ಅದು ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಆದರೆ ಕೋಡ್ ಮೂಲಕ ಹೋಗುವುದು ಮತ್ತು ಎಲ್ಲೆಡೆ setFetchSize ಅನ್ನು ಹೊಂದಿಸುವುದು ಅನಾನುಕೂಲವಾಗಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ಸಂಪೂರ್ಣ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವನ್ನು ಹೇಳುವ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಮಾಡಿದ್ದೇವೆ.

ಅದನ್ನೇ ನಾವು ಹೇಳಿದ್ದೇವೆ. ನಿಯತಾಂಕವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ಮತ್ತು ನಮಗೆ ಏನು ಸಿಕ್ಕಿತು? ನಾವು ಸಣ್ಣ ಮೊತ್ತವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದರೆ, ಉದಾಹರಣೆಗೆ, ನಾವು ಒಂದು ಬಾರಿಗೆ 10 ಸಾಲುಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿದರೆ, ನಾವು ತುಂಬಾ ದೊಡ್ಡ ಓವರ್ಹೆಡ್ ವೆಚ್ಚಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, ಈ ಮೌಲ್ಯವನ್ನು ಸುಮಾರು ನೂರಕ್ಕೆ ಹೊಂದಿಸಬೇಕು.

ತಾತ್ತ್ವಿಕವಾಗಿ, ಸಹಜವಾಗಿ, ಬೈಟ್‌ಗಳಲ್ಲಿ ಅದನ್ನು ಹೇಗೆ ಮಿತಿಗೊಳಿಸಬೇಕೆಂದು ನೀವು ಇನ್ನೂ ಕಲಿಯಬೇಕಾಗಿದೆ, ಆದರೆ ಪಾಕವಿಧಾನ ಹೀಗಿದೆ: ಡೀಫಾಲ್ಟ್‌ರೋಫೆಚ್‌ಸೈಜ್ ಅನ್ನು ನೂರಕ್ಕೂ ಹೆಚ್ಚು ಹೊಂದಿಸಿ ಮತ್ತು ಸಂತೋಷವಾಗಿರಿ.

ಡೇಟಾವನ್ನು ಸೇರಿಸಲು ಹೋಗೋಣ. ಅಳವಡಿಕೆ ಸುಲಭ, ವಿವಿಧ ಆಯ್ಕೆಗಳಿವೆ. ಉದಾಹರಣೆಗೆ, INSERT, VALUES. ಇದು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ. ನೀವು "ಇನ್ಸರ್ಟ್ ಸೆಲೆಕ್ಟ್" ಎಂದು ಹೇಳಬಹುದು. ಆಚರಣೆಯಲ್ಲಿ ಇದು ಒಂದೇ ವಿಷಯ. ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ.

ನೀವು ಬ್ಯಾಚ್ ಹೇಳಿಕೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕಾಗಿದೆ ಎಂದು ಪುಸ್ತಕಗಳು ಹೇಳುತ್ತವೆ, ಹಲವಾರು ಆವರಣಗಳೊಂದಿಗೆ ನೀವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಆಜ್ಞೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು ಎಂದು ಪುಸ್ತಕಗಳು ಹೇಳುತ್ತವೆ. ಮತ್ತು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಅದ್ಭುತ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದೆ - ನೀವು ನಕಲಿಸಬಹುದು, ಅಂದರೆ ಅದನ್ನು ವೇಗವಾಗಿ ಮಾಡಬಹುದು.

ನೀವು ಅದನ್ನು ಅಳತೆ ಮಾಡಿದರೆ, ನೀವು ಮತ್ತೆ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ಆವಿಷ್ಕಾರಗಳನ್ನು ಮಾಡಬಹುದು. ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ? ಅನಗತ್ಯ ಆಜ್ಞೆಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಬಾರದು ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸಬಾರದು ಎಂದು ನಾವು ಬಯಸುತ್ತೇವೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ, TCP ಇದನ್ನು ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವಲ್ಲಿ ನಿರತರಾಗಿದ್ದರೆ, ನಮಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಳುಹಿಸುವ ಪ್ರಯತ್ನಗಳಲ್ಲಿ ಡೇಟಾಬೇಸ್ ವಿನಂತಿಗಳನ್ನು ಓದುವುದಿಲ್ಲ. ಅಂತಿಮ ಫಲಿತಾಂಶವೆಂದರೆ ಕ್ಲೈಂಟ್ ವಿನಂತಿಯನ್ನು ಓದಲು ಡೇಟಾಬೇಸ್‌ಗಾಗಿ ಕಾಯುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಓದಲು ಡೇಟಾಬೇಸ್ ಕಾಯುತ್ತದೆ.

ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ನಿಯತಕಾಲಿಕವಾಗಿ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿ ನೆಟ್‌ವರ್ಕ್ ಸಂವಹನಗಳು, ಹೆಚ್ಚುವರಿ ಸಮಯ ವ್ಯರ್ಥ.

ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಹೆಚ್ಚು ಸೇರಿಸುತ್ತೇವೆ, ಅದು ಕೆಟ್ಟದಾಗುತ್ತದೆ. ಚಾಲಕನು ಸಾಕಷ್ಟು ನಿರಾಶಾವಾದಿಯಾಗಿದ್ದಾನೆ ಮತ್ತು ಸಾಲುಗಳ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿ ಪ್ರತಿ 200 ಸಾಲುಗಳಿಗೆ ಒಮ್ಮೆ ಅವುಗಳನ್ನು ಆಗಾಗ್ಗೆ ಸೇರಿಸುತ್ತಾನೆ.

https://github.com/pgjdbc/pgjdbc/pull/380

ನೀವು ಕೇವಲ ಒಂದು ಸಾಲನ್ನು ಸರಿಪಡಿಸುತ್ತೀರಿ ಮತ್ತು ಎಲ್ಲವೂ 10 ಪಟ್ಟು ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಹಾಗೆ ಆಗುತ್ತದೆ. ಏಕೆ? ಎಂದಿನಂತೆ, ಈ ರೀತಿಯ ಸ್ಥಿರವನ್ನು ಈಗಾಗಲೇ ಎಲ್ಲೋ ಬಳಸಲಾಗಿದೆ. ಮತ್ತು "128" ಮೌಲ್ಯವು ಬ್ಯಾಚಿಂಗ್ ಅನ್ನು ಬಳಸಬಾರದು ಎಂದರ್ಥ.

ಜಾವಾ ಮೈಕ್ರೋಬೆಂಚ್ಮಾರ್ಕ್ ಸರಂಜಾಮು

ಇದನ್ನು ಅಧಿಕೃತ ಆವೃತ್ತಿಯಲ್ಲಿ ಸೇರಿಸದಿರುವುದು ಒಳ್ಳೆಯದು. ಬಿಡುಗಡೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಕಂಡುಹಿಡಿಯಲಾಯಿತು. ನಾನು ನೀಡುವ ಎಲ್ಲಾ ಅರ್ಥಗಳು ಆಧುನಿಕ ಆವೃತ್ತಿಗಳನ್ನು ಆಧರಿಸಿವೆ.

ಅದನ್ನು ಪ್ರಯತ್ನಿಸೋಣ. ನಾವು InsertBatch ಅನ್ನು ಸರಳವಾಗಿ ಅಳೆಯುತ್ತೇವೆ. ನಾವು InsertBatch ಅನ್ನು ಹಲವಾರು ಬಾರಿ ಅಳೆಯುತ್ತೇವೆ, ಅಂದರೆ ಒಂದೇ ವಿಷಯ, ಆದರೆ ಹಲವು ಮೌಲ್ಯಗಳಿವೆ. ಟ್ರಿಕಿ ಮೂವ್. ಪ್ರತಿಯೊಬ್ಬರೂ ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಇದು ಸರಳವಾದ ಕ್ರಮವಾಗಿದೆ, ನಕಲು ಮಾಡುವುದಕ್ಕಿಂತ ಸುಲಭವಾಗಿದೆ.

ನೀವು ನಕಲು ಮಾಡಬಹುದು.

ಮತ್ತು ನೀವು ಇದನ್ನು ರಚನೆಗಳಲ್ಲಿ ಮಾಡಬಹುದು. ಬಳಕೆದಾರರ ಡೀಫಾಲ್ಟ್ ಪ್ರಕಾರವನ್ನು ಘೋಷಿಸಿ, ರಚನೆಯನ್ನು ರವಾನಿಸಿ ಮತ್ತು ನೇರವಾಗಿ ಟೇಬಲ್‌ಗೆ ಸೇರಿಸಿ.

ನೀವು ಲಿಂಕ್ ಅನ್ನು ತೆರೆದರೆ: pgjdbc/ubenchmsrk/InsertBatch.java, ನಂತರ ಈ ಕೋಡ್ GitHub ನಲ್ಲಿದೆ. ಅಲ್ಲಿ ಯಾವ ವಿನಂತಿಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ನಿರ್ದಿಷ್ಟವಾಗಿ ನೋಡಬಹುದು. ಪರವಾಗಿಲ್ಲ.

ನಾವು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಮತ್ತು ಬ್ಯಾಚ್ ಅನ್ನು ಬಳಸದಿರುವುದು ಅಸಾಧ್ಯವೆಂದು ನಾವು ಅರಿತುಕೊಂಡ ಮೊದಲ ವಿಷಯ. ಎಲ್ಲಾ ಬ್ಯಾಚಿಂಗ್ ಆಯ್ಕೆಗಳು ಶೂನ್ಯವಾಗಿರುತ್ತದೆ, ಅಂದರೆ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಸಮಯವು ಒಂದು-ಬಾರಿ ಎಕ್ಸಿಕ್ಯೂಶನ್‌ಗೆ ಹೋಲಿಸಿದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಶೂನ್ಯವಾಗಿರುತ್ತದೆ.

ನಾವು ಡೇಟಾವನ್ನು ಸೇರಿಸುತ್ತೇವೆ. ಇದು ತುಂಬಾ ಸರಳವಾದ ಟೇಬಲ್. ಮೂರು ಕಾಲಮ್‌ಗಳು. ಮತ್ತು ನಾವು ಇಲ್ಲಿ ಏನು ನೋಡುತ್ತೇವೆ? ಈ ಎಲ್ಲಾ ಮೂರು ಆಯ್ಕೆಗಳನ್ನು ಸರಿಸುಮಾರು ಹೋಲಿಸಬಹುದು ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಮತ್ತು ನಕಲು, ಸಹಜವಾಗಿ, ಉತ್ತಮವಾಗಿದೆ.

ನಾವು ತುಣುಕುಗಳನ್ನು ಸೇರಿಸಿದಾಗ ಇದು. ನಾವು ಒಂದು ಮೌಲ್ಯಗಳು, ಎರಡು ಮೌಲ್ಯಗಳು, ಮೂರು ಮೌಲ್ಯಗಳು ಮೌಲ್ಯಗಳು ಅಥವಾ ಅಲ್ಪವಿರಾಮದಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾದ 10 ಮೌಲ್ಯಗಳನ್ನು ನಾವು ಸೂಚಿಸಿದಾಗ. ಇದು ಈಗ ಕೇವಲ ಸಮತಲವಾಗಿದೆ. 1, 2, 4, 128. ನೀಲಿ ಬಣ್ಣದಲ್ಲಿ ಚಿತ್ರಿಸಲಾದ ಬ್ಯಾಚ್ ಇನ್ಸರ್ಟ್ ಅವನಿಗೆ ಹೆಚ್ಚು ಉತ್ತಮವಾಗಿದೆ ಎಂದು ನೋಡಬಹುದು. ಅಂದರೆ, ನೀವು ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದನ್ನು ಸೇರಿಸಿದಾಗ ಅಥವಾ ನೀವು ಒಂದೇ ಬಾರಿಗೆ ನಾಲ್ಕನ್ನು ಸೇರಿಸಿದಾಗ, ಅದು ಎರಡು ಪಟ್ಟು ಉತ್ತಮವಾಗಿರುತ್ತದೆ, ಏಕೆಂದರೆ ನಾವು ಮೌಲ್ಯಗಳಲ್ಲಿ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ತುಂಬಿದ್ದೇವೆ. ಕಡಿಮೆ ಎಕ್ಸಿಕ್ಯೂಟ್ ಕಾರ್ಯಾಚರಣೆಗಳು.

ಸಣ್ಣ ಸಂಪುಟಗಳಲ್ಲಿ COPY ಅನ್ನು ಬಳಸುವುದು ಅತ್ಯಂತ ಭರವಸೆಯಿಲ್ಲ. ನಾನು ಮೊದಲ ಎರಡನ್ನೂ ಸೆಳೆಯಲಿಲ್ಲ. ಅವರು ಸ್ವರ್ಗಕ್ಕೆ ಹೋಗುತ್ತಾರೆ, ಅಂದರೆ, ನಕಲಿಸಲು ಈ ಹಸಿರು ಸಂಖ್ಯೆಗಳು.

ನೀವು ಕನಿಷ್ಟ ನೂರು ಸಾಲುಗಳ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವಾಗ COPY ಅನ್ನು ಬಳಸಬೇಕು. ಈ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುವ ಓವರ್ಹೆಡ್ ದೊಡ್ಡದಾಗಿದೆ. ಮತ್ತು, ಪ್ರಾಮಾಣಿಕವಾಗಿ, ನಾನು ಈ ದಿಕ್ಕಿನಲ್ಲಿ ಅಗೆಯಲಿಲ್ಲ. ನಾನು ಬ್ಯಾಚ್ ಅನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ್ದೇನೆ, ಆದರೆ ನಕಲು ಮಾಡಿಲ್ಲ.

ನಾವು ಮುಂದೆ ಏನು ಮಾಡಬೇಕು? ನಾವು ಅದನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ನಾವು ರಚನೆಗಳನ್ನು ಅಥವಾ ಹಲವಾರು ಅರ್ಥಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಬುದ್ಧಿವಂತ ಬ್ಯಾಕ್ತ್ ಅನ್ನು ಬಳಸಬೇಕೆಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ.

ಇಂದಿನ ವರದಿಯಿಂದ ನೀವು ಏನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು?

• ಸಿದ್ಧಪಡಿಸಿದ ಹೇಳಿಕೆ ನಮ್ಮ ಸರ್ವಸ್ವವಾಗಿದೆ. ಇದು ಉತ್ಪಾದಕತೆಗೆ ಬಹಳಷ್ಟು ನೀಡುತ್ತದೆ. ಇದು ಮುಲಾಮುದಲ್ಲಿ ದೊಡ್ಡ ಫ್ಲಾಪ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ.
• ಮತ್ತು ನೀವು 6 ಬಾರಿ EXPLIN ANYZE ಮಾಡಬೇಕಾಗಿದೆ.
• ಮತ್ತು ನಮ್ಮ ಸಮಸ್ಯಾತ್ಮಕ ಪ್ರಶ್ನೆಗಳ ಉಳಿದ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವನ್ನು ಸರಿಪಡಿಸಲು ನಾವು OFFSET 0 ಮತ್ತು +0 ನಂತಹ ತಂತ್ರಗಳನ್ನು ದುರ್ಬಲಗೊಳಿಸಬೇಕಾಗಿದೆ.

ಮೂಲ: www.habr.com