Skip to main content
هذه الإعدادات متاحة في system.settings، ويجري توليدها تلقائيًا من المصدر.

apply_deleted_mask

يُفعّل تصفية الصفوف المحذوفة باستخدام DELETE الخفيف. وإذا كان معطّلًا، فسيتمكّن الاستعلام من قراءة تلك الصفوف. ويكون ذلك مفيدًا في سيناريوهات تصحيح الأخطاء و”إلغاء الحذف”

apply_mutations_on_fly

إذا كانت القيمة true، فستُطبَّق عمليات mutations ‏(UPDATEs وDELETEs) التي لم تُطبَّق فعليًا بعد في data part عند تنفيذ استعلامات SELECT.

apply_prewhere_after_final

عند التمكين، تُطبَّق شروط PREWHERE بعد معالجة FINAL في ReplacingMergeTree والمحركات المشابهة. وقد يكون ذلك مفيدًا عندما يشير PREWHERE إلى أعمدة قد تختلف قيمها بين الصفوف المكررة، وتريد أن يحدِّد FINAL الصف المعتمد قبل التصفية. وعند التعطيل، يُطبَّق PREWHERE أثناء القراءة. ملاحظة: يُؤجَّل تطبيق PREWHERE أيضًا، بغض النظر عن هذا الإعداد، كلما أُجِّل تطبيق سياسة الصف بسبب apply_row_policy_after_final، لأن سياسة الصف يجب أن تُطبَّق قبل PREWHERE. ويحدث ذلك عندما يكون تعبير السياسة غير حتمي، أو يقرأ عمودًا غير موجود في ORDER BY، أو يقرأ عمودًا في ORDER BY يكون نوعه من أنواع الفاصلة العائمة أو يحتوي على نوع منها. القيم الممكنة:
  • 0 — يُطبَّق PREWHERE قبل FINAL، ما لم تؤدِّ سياسة صف مؤجَّلة إلى تأجيله أيضًا (الافتراضي).
  • 1 — يُطبَّق PREWHERE بعد FINAL.

apply_row_policy_after_final

عند التمكين، تُطبَّق سياسات الصف بعد معالجة FINAL في جداول *MergeTree. (وخاصة ReplacingMergeTree) عندما يُؤجَّل تطبيق السياسة بهذه الطريقة، يُؤجَّل تطبيق PREWHERE معها حتى تظل السياسة تُطبَّق أولًا (انظر apply_prewhere_after_final لتأجيل تطبيق PREWHERE دون شروط). عند التعطيل، تُطبَّق سياسات الصف قبل FINAL، مما قد يؤدي إلى نتائج مختلفة عندما تقوم السياسة بتصفية صفوف يُفترض استخدامها لإزالة التكرار في ReplacingMergeTree أو محركات مشابهة. إذا كان تعبير سياسة الصف حتميًا ويعتمد فقط على أعمدة لا تحتوي على قيم بفاصلة عائمة في ORDER BY، فسيظل يُطبَّق قبل FINAL كتحسين، لأن هذا النوع من التصفية لا يمكن أن يؤثر في نتيجة إزالة التكرار. وتُستثنى الأعمدة ذات الفاصلة العائمة أو الأعمدة التي تحتوي على قيم ذات فاصلة عائمة (مثل Tuple(Float64, ...) وArray(Float64) وNullable(Float64) وغيرها) لأن -0.0 و0.0 يُعدّان مفتاحًا واحدًا عند إزالة التكرار، بينما يمكن لشرط السياسة التمييز بينهما. القيم الممكنة:
  • 0 — تُطبَّق سياسة الصف قبل FINAL.
  • 1 — تُطبَّق سياسة الصف بعد FINAL (افتراضيًا).

apply_settings_from_server

ما إذا كان ينبغي للعميل قبول الإعدادات من الخادم. لا يؤثر هذا إلا في العمليات التي تُنفَّذ على جهة العميل، وخصوصًا parsing لبيانات إدخال INSERT وformatting لنتيجة الاستعلام. يحدث معظم query execution على الخادم، ولا يتأثر بهذا الإعداد. عادةً، ينبغي تعيين هذا الإعداد في profile المستخدم (users.xml أو استعلامات مثل ALTER USER)، وليس عبر العميل (وسائط سطر أوامر العميل، أو استعلام SET، أو قسم SETTINGS في استعلام SELECT). ويمكن تغييره عبر العميل إلى false، لكن لا يمكن تغييره إلى true (لأن الخادم لن يرسل الإعدادات إذا كان profile المستخدم يحتوي على apply_settings_from_server = false). لاحظ أنه في البداية (24.12) كان هناك server setting (send_settings_to_client)، ولكن استُبدل لاحقًا بهذا client setting لتحسين سهولة الاستخدام.

apply_string_filters_during_scan

ينفّذ pushdown لشروط البحث عن السلاسل الفرعية في أعمدة String من PREWHERE إلى فحص العمود. عندما يحتوي شرط PREWHERE على حدٍّ مقترن يبحث عن سلسلة فرعية غير فارغة في عمود من النوع String (أو Nullable(String)) (LIKE أو position أو startsWith أو endsWith أو المساواة مع سلسلة غير فارغة)، يتحقق القارئ من مطابقة كل قيمة لهذا الشرط أثناء إلغاء التسلسل، ويقرأ القيم غير المطابقة على أنها سلاسل فارغة. ويؤدي ذلك إلى تسريع القراءة وخفض استهلاك الذاكرة عندما يكون الشرط انتقائيًا، لأن بيانات القيم غير المطابقة لا تُنسخ إلى العمود. ولا تتغير نتيجة الاستعلام، لأن PREWHERE يستبعد حتمًا الصفوف ذات القيم غير المطابقة، ولأن هذه الشروط لا تتطابق أبدًا مع سلسلة فارغة. يُعطَّل عامل التصفية تكيفيًا أثناء التشغيل إذا تبيّن أنه غير انتقائي. يسمح هذا الإعداد أيضًا لتحسين نقل الشروط من WHERE إلى PREWHERE بنقل شروط البحث عن السلاسل الفرعية (LIKE وposition وstartsWith وendsWith) حتى عندما تستخدم جميع الأعمدة المستعلَم عنها (وهو أمر لا جدوى منه عادةً، لكن الفحص نفسه يصبح أقل تكلفة مع هذا الإعداد). أما المساواة مع سلسلة ثابتة فلا تُنقل لهذا الغرض، لكنها تظل تُطبَّق أثناء الفحص إذا كانت موجودة أصلًا في PREWHERE. مدعوم عند القراءة من جداول MergeTree ومن صيغة Parquet. لاحظ أن تقدير بايتات الإدخال الذي يُجمع لاتخاذ القرار التلقائي بشأن النسخ المتماثلة المتوازية (RuntimeDataflowStatisticsInputBytes) يعتمد على حجم الكتل المقروءة في الذاكرة، ولذلك يُقدِّر كمية البيانات المقروءة من القرص بأقل من حجمها الفعلي عندما تُستبدل القيم بسلاسل فارغة. القيم الممكنة:
  • 0 — معطَّل.
  • 1 — مفعَّل.