يختلف Postgresql عن DBMSs الأخرى في أنه أثناء عملية UPDATE ، لا تحدث تغييرات في الصف الموجود ، وبدلاً من ذلك يتم عمل نسخة من الصف تختلف عن الأصل مع قيم الأعمدة المتأثرة بالتحديث - فهي قديمة في الأصل وتغييرها في النسخة. هذا النهج ، من ناحية ، يسمح لك بتجنب الأقفال أثناء تنفيذ طلبات القراءة والكتابة ، ومن ناحية أخرى ، فإنه يخلق الحاجة إلى مسح الإصدارات القديمة من السلاسل التي لن يقرأها أحد من أي وقت مضى. فيما يتعلق بهذه الميزة المعمارية ، غالبًا ما يطرح السؤال عما سيحدث إذا كنت بحاجة إلى تخزين في قاعدة البيانات شيئًا مثل وقت آخر وصول إلى البيانات الذي لم يتغير. هل ستستجيب للأداء؟ هل سيؤدي ذلك إلى إعادة هيكلة مستمرة للمؤشرات؟
باختصار ، نعم ، لن يذهب تطبيق Copy On Write إلى أي مكان ، ولكن في العديد من الحالات لا يمكن إعادة إنشاء الفهارس ، وذلك بفضل HOT.
الكومة tuples فقط ، والمعروفة أيضًا باسم HOT ، هو تحسين يستخدمه Postgres لتقليل مقدار الإدخال / الإخراج المطلوب للتحديثات. بسبب MVCC ، يتكون التحديث في Postgres من البحث عن صف للتحديث وإدراج إصدارات جديدة من الصف في قاعدة البيانات. العيب الرئيسي لهذا الإجراء هو الحاجة إلى إعادة إضافة صف إلى كل فهرس.
يتطلب ذلك إدخال / إخراج أكثر كثيرًا لأنه يجب إعادة إدراج الصف في كل فهرس في الجدول. تنشأ الحاجة إلى إعادة الإدماج لأن الوضع الفعلي للإصدار الجديد من سطر على القرص يختلف عن الوضع الفعلي للإصدار القديم.
لتقليل مقدار الإدخال / الإخراج المطلوب لـ UPDATE ، أضاف فريق Postgres HOT إلى Postgres. الفكرة وراء HOT بسيطة نسبيا. عند تحديث السطر ، إن أمكن ، ستضع Postgres نسخة جديدة من الخط فورًا بعد النسخة القديمة من الخط. بالإضافة إلى ذلك ، في النسخة القديمة من السلسلة ، يتم وضع علامة خاصة بحيث يعرف Postgres أن النسخة الجديدة من السلسلة موجودة مباشرة بعد النسخة القديمة. لذلك ، تحديث كافة الفهارس غير ضروري.
أثناء الفحص حسب الفهرس الذي تمر به نسخة جديدة من السلسلة ، سيجد مرشح Postgres النسخة القديمة من السلسلة. نظرًا لوجود تسمية خاصة على النسخة القديمة من الخط ، ستفهم Postgres أن النسخة الجديدة من الخط تقع مباشرة بعد النسخة القديمة وستجد النسخة الجديدة وتستخدمها. اتضح أن Postgres في مثل هذه الحالات يمكن أن تتصرف كما لو كانت جميع الفهارس تشير إلى نسخة جديدة من السلسلة ، وأنها لا تحتاج إلى إعادة بنائها.
الآن يتم إشراك HOT فقط عندما يتم تضمين الأعمدة غير القابلة للفهرسة فقط في التحديث. إذا تم تضمين عمود واحد على الأقل مشترك في التحديث في الفهرس ، فلن يمكن تطبيق HOT. في هذه الحالة ، هناك العديد من المشاكل مع استخدام HOT. على سبيل المثال ، عندما يتم فهرسة الفهرس الموجود في العمود الذي يحتاج إلى تحديث بواسطة المسح الضوئي ، فإن النسخة القديمة من الخط تقع في مسند الفحص ، لكن النسخة الجديدة لا تفعل ذلك. في هذه الحالة ، ستحاول Postgres استخدام الفهرس للعثور بسرعة على جميع الصفوف المناسبة لاستعلام التقييم ، وفي حالة الأعمدة التي تم تحديثها باستخدام HOT ، ستنتج نسخة جديدة من الصف لا تتطابق مع توقع التقييم. بسبب هذا القيد (أن HOT لا يعمل عندما يتم تضمين الأعمدة القابلة للفهرسة في التحديث) ، يستطيع Postgres ضمان أنه عندما يحاول العثور على صفوف مناسبة للمسند الذي يتم من خلاله تمرير المؤشر ، ثم إذا تطابقت المسند مع الإصدار القديم من الصف ، فإن الإصدار الجديد من الصف كما يناسبه والعكس صحيح.
قيد التطوير حاليًا ملحق HOT يسمى WARM ، والذي يعمل أيضًا عند تحديث الأعمدة التي يتم إنشاء الفهارس عليها. الفكرة وراء WARM هي وضع صف جديد فورًا بعد القديم وتحديث الصف للفهارس التي غيرت الأعمدة. هذا يعقد الموقف الموصوف إلى حد كبير ، لأن Postgres الآن يحتاج إلى طريقة لتحديد ما إذا كان الصف يمرر مرشح الفهرس أم لا.
ملاحظة: في المقالة الأصلية ، يتم وصف آلية HOT ، ولكن هنا نضع في اعتبارنا الآلية التي يشارك فيها فقط tuples ، وللمصطلح نفسه معنى منفصل.
كومة tuple فقط هي مجرد نسخة جديدة من الخط. غريب كما يبدو ، Heap عبارة عن جدول ، ويعني Heap فقط أنه لا يمكن العثور على هذا الخط إلا من خلال السلسلة التي تؤدي من الإصدار الأقدم من الخط الذي يسمى الجذر.