حذف pgrust: ورودی تقلب می‌کند (هسته‌های هر پرس و جو و ذخیره نتایج)

این ورودی pgrust (اضافه شده در #1163، به روز رسانی به v0.4-preview در #2106) را از معیار حذف می کند. نتایجی که گزارش می‌کند توسط ماشین‌هایی تولید می‌شوند که به طور خاص برای 43 پرس‌و‌جوی ClickBench نوشته شده‌اند، و اجرای داغ آن پاسخ‌های ذخیره‌شده قبلی را دوباره پخش می‌کند. هر دو قوانین را نقض می‌کنند: حافظه‌های پنهان نتایج پرس و جو و حافظه‌های پنهان نزدیک انتهای خط لوله باید غیرفعال شوند، و ورودی برچسب تنظیم شده است: نه در حالی که برای این جستارهای دقیق تنظیم شده است.

همه موارد زیر در برابر نسخه باینری انتشار نسخه 4-پیش نمایش (pgrust.com/downloads/v0.4-preview/، دانلودهای یک نصب) و منبع عمومی نسخه 3 (github.com/malisper/pgrust) تأیید شد. منبع v0.4-preview منتشر نشده است. باینری خود را pgrust 0.3-beta معرفی می کند.

باینری انتشار aarch64 این مسیرهای منبع را تعبیه می کند:

اعداد عبارتند از اعداد جستجوی ClickBench. تطبیق‌کنندگان طرحی که به این هسته‌ها ارسال می‌شوند، پیام‌های امتناع به نام معیار را منتشر می‌کنند، برای مثال:

همچنین یک دکمه محیطی وجود دارد که به معنای واقعی کلمه PGRUST_GRAVITY_Q20_VARIANT نام دارد.

منبع عمومی نسخه 3 این طرح را تأیید می‌کند: crates/backend/executor/sqe/rig/plans/clickbench.ron در سربرگ خود به‌عنوان «طرح‌های فیزیکی با دست برای همه 43 کوئری‌های ClickBench» توصیف شده است، و query-clickbench.sql (معیار به‌لفظی شامل SQL می‌شود! . آن فایل Q0، Q1، Q2، Q3، Q6، Q19 و Q29 را به‌عنوان MetadataAnswer طبقه‌بندی می‌کند (پاسخ از آمار هر قسمت، بدون اسکن)، خاطرنشان می‌کند که «خطوط پاسخ Q19 از ثابت محمول بازسازی می‌شوند»، که Q29 یک بازنویسی جبری SUM(x+k) است و با Q+A, COUNT(a) و SUMtax به دنبال آن است.

به یک ستون مشتق شده ادامه دار "با عرض بیت پخته 26/6/20" بستگی دارد. عبارت منظم Q28 یک جدول کد یک‌ ورودی است (HOST_EXTRACT_PATTERN = ^https?://(?:www\.)?([^/]+)/.*$)، و یک نظر برنامه‌ریز چنین می‌گوید "تنها شکل 43 دارای HAVING: COUNT(*) > k".

برای Q20، Q21 و Q23 یادداشت های طرح می گویند: "نمایش داغ = برابر کردن خالص روی احکام ذخیره شده - صفر ستون لمس شد؛ انتخاب پاسخ است". در مورد انتشار گزارش های باینری توضیح دهید SQE: موتور (خانواده: پخش پنجره) برای Q20 و خانواده: متاپاسخ برای Q1 با اسکن علامت گذاری شده هرگز اجرا نشده است.

اندازه‌گیری محلی بر روی دستگاه 96 هسته‌ای Graviton (Neoverse-V2)، با استفاده از اسکریپت‌ها و پیکربندی ورودی، با چرخه سرد واقعی (توقف، رها کردن حافظه پنهان، شروع) مانند درایور:

راه اندازی مجدد دوم Q20 را به 11.2 ثانیه و سپس 3 میلی ثانیه برگرداند. سرعت گرم واقعی موتور برای اسکن زیر رشته ای چند صد میلی ثانیه است که تقریبا همان کاری است که ClickHouse روی همان سخت افزار انجام می دهد. اعداد داغ منتشر شده (7 تا 23 میلی ثانیه برای Q20) بازپخش احکام اجرای قبلی است.

ارسال نسخه 2 (#1163) یک حافظه پنهان مشابه (pgrust.condition_cache = روشن) را فاش کرد و پیشنهاد خاموش کردن آن را داد. به روز رسانی نسخه 4 آن README و تنظیمات را حذف کرد. اکنون هیچ پیکربندی کش را غیرفعال نمی‌کند: با pgrust.gravity_entry = خاموش و pgrust.condition_cache = خاموش، یک LIKE تکراری همچنان در 3 تا 4 میلی‌ثانیه برمی‌گردد.

موتور هیچ مسیر اجرای کلی برای جدول ستونی ندارد. پرس‌و‌جوهای بنچمارک با آشفتگی بی‌اهمیت با ERROR شکست می‌خورند: sqe: عبارت روی رابطه ستونی "Hits" ارائه نمی‌شود و جزئیات خطا می‌گوید "موتور sqe اشکال ستونی را بدون بازگشت ارائه می‌کند؛ شکلی که ارائه نشده است به جای اینکه آهسته اجرا شود، با صدای بلند خراب می‌شود". 20 مورد از 67 کاوشگر نزدیک به معیار و 3 مورد از 49 نوع آشفته رد شدند، از جمله:

INSERT، UPDATE و DELETE نیز در جدول پشتیبانی نمی شوند (pgrcolumnar2 از INSERT پشتیبانی نمی کند).

پاسخ‌های 43 عبارت خود درست هستند: در مقایسه با کلیک‌هاوس محلی بر روی همان hits.parquet، 30 مورد دقیقا مطابقت دارند و تفاوت‌های باقی‌مانده در LIMIT جستارها (تأیید شده به صورت جداگانه) معتبر هستند. مشکل نتایج اشتباه نیست. این است که نتایج یک جدول جستجوی معیار را اندازه گیری می کند، نه یک پایگاه داده.

هنگام بارگیری خطایی روی داد. لطفا این صفحه را دوباره بارگیری کنید.

از آنجایی که این موضوع در کانال های دیگر شنیده می شود، من پاسخی را در HN اینجا نوشتم: https://news.ycombinator.com/item?id=50209450