عملکرد فهرست و جزئیات بیشتر

ایجاد فهرست - یک فهرست جدید را تعریف کنید

خلاصه

ایجاد شاخص [منحصر به فرد] [همزمان] [[اگر وجود نداشته باشد]نام] در [فقط]جدول_ نام[ استفاده كردنروش ] ( <نام ستون | ( اصطلاح )>[جمع کردنجمع شدن ] [ عظیم [ ( opclass_parameter = ارزش[، ،]]]] [ASC |DESC] [NULLS] [،.] ) [ عبارتند از (نام ستون[، ،]]] [تهی [نه] متمایز] [با (انبار [= ارزش] [،.])] [TABRESPACEtablespace_name] [ جایی کهمستحق ]

شرح

ایجاد شاخص در ستون (های) مشخص شده از رابطه مشخص شده ، که می تواند یک جدول یا یک نمای مادی باشد. از فهرست ها در درجه اول برای تقویت عملکرد پایگاه داده استفاده می شود (هرچند استفاده نامناسب می تواند منجر به عملکرد کندتر شود).

قسمت اصلی (های) برای فهرست به عنوان نام ستون مشخص شده است ، یا به عنوان عبارات به عنوان عباراتی که در پرانتز نوشته شده است. اگر روش شاخص از شاخص های چند رنگ پشتیبانی می کند ، می توان زمینه های مختلفی را مشخص کرد.

یک قسمت فهرست می تواند عبارتی باشد که از مقادیر یک یا چند ستون از ردیف جدول محاسبه شده است. این ویژگی می تواند برای دستیابی سریع به داده ها بر اساس برخی از تغییر داده های اساسی استفاده شود. به عنوان مثال ، یک شاخص محاسبه شده در بالا (col) به بند اجازه می دهد که در آن بالا (col) = 'Jim' از یک شاخص استفاده کند.

PostgreSQL روشهای شاخص B-Tree ، Hash ، Gist ، SP-Gist ، Gin و Brin را ارائه می دهد. کاربران همچنین می توانند روشهای شاخص خود را تعریف کنند ، اما این نسبتاً پیچیده است.

هنگامی که بند جایی وجود دارد ، یک شاخص جزئی ایجاد می شود. شاخص جزئی شاخصی است که فقط بخشی از یک جدول را شامل می شود ، معمولاً بخشی که برای نمایه سازی از بقیه جدول مفید است. به عنوان مثال ، اگر شما یک جدول دارید که شامل سفارشات صورتحساب و بدون درج است که در آن سفارشات بدون استفاده بخش کوچکی از جدول کل را در خود جای می دهد و با این وجود این یک بخش اغلب استفاده شده است ، می توانید با ایجاد یک شاخص در آن بخش ، عملکرد را بهبود بخشید. یکی دیگر از برنامه های ممکن استفاده از جایی است که با منحصر به فرد برای اجرای منحصر به فرد بودن در زیر مجموعه ای از یک جدول. برای بحث بیشتر به بخش 11. 8 مراجعه کنید.

عبارتی که در بند WHERE استفاده می شود ، فقط به ستون های جدول زیرین می تواند اشاره کند ، اما می تواند از همه ستون ها استفاده کند ، نه فقط مواردی که در آن فهرست بندی می شوند. در حال حاضر ، زیرمجموعه ها و عبارات کل نیز در جایی ممنوع است. همین محدودیت ها در زمینه های شاخص که عبارات هستند اعمال می شود.

همه توابع و عملگرهای مورد استفاده در تعریف شاخص باید "تغییر ناپذیر" باشند، یعنی نتایج آنها باید فقط به آرگومان های آنها بستگی داشته باشد و هرگز به هیچ تاثیر خارجی (مانند محتوای جدول دیگر یا زمان فعلی) بستگی ندارد. این محدودیت تضمین می کند که رفتار شاخص به خوبی تعریف شده است. برای استفاده از یک تابع تعریف شده توسط کاربر در یک عبارت شاخص یا عبارت WHERE، به یاد داشته باشید که هنگام ایجاد تابع غیرقابل تغییر علامت گذاری کنید.

مولفه های

منحصر بفرد

باعث می شود که سیستم هنگام ایجاد ایندکس (اگر داده از قبل وجود داشته باشد) و هر بار که داده اضافه می شود، مقادیر تکراری را در جدول بررسی کند. تلاش برای درج یا به روزرسانی داده ها که منجر به ورودی های تکراری می شود، خطا ایجاد می کند.

محدودیت های اضافی اعمال می شود زمانی که شاخص های منحصر به فرد به جداول پارتیشن بندی شده اعمال می شود. ایجاد جدول را ببینید.

وقتی از این گزینه استفاده می شود، PostgreSQL ایندکس را بدون گرفتن قفلی که از درج، به روز رسانی یا حذف همزمان روی جدول جلوگیری می کند، می سازد. در حالی که یک ساختار شاخص استاندارد نوشتن را روی جدول قفل می کند (اما نمی خواند) تا زمانی که تمام شود. چندین اخطار وجود دارد که هنگام استفاده از این گزینه باید از آنها آگاه بود - به نمایه های ساختمانی همزمان در زیر مراجعه کنید.

برای جداول موقت، CREATE INDEX همیشه غیرهمزمان است، زیرا هیچ جلسه دیگری نمی تواند به آنها دسترسی داشته باشد، و ایجاد فهرست غیرهمزمان ارزان تر است.

اگر رابطه ای با همین نام از قبل وجود داشته باشد، خطا ایجاد نکنید. در این مورد اخطاریه صادر می شود. توجه داشته باشید که هیچ تضمینی وجود ندارد که شاخص موجود چیزی شبیه به آنچه ایجاد شده بود باشد. زمانی که IF NOT EXISTS مشخص شده باشد، نام فهرست مورد نیاز است.

بند اختیاری INCLUDE فهرستی از ستون ها را مشخص می کند که به عنوان ستون های غیرکلیدی در فهرست گنجانده می شوند. یک ستون غیرکلیدی را نمی توان در صلاحیت جستجوی اسکن نمایه استفاده کرد و برای اهداف منحصر به فرد بودن یا محدودیت های حذف اعمال شده توسط نمایه نادیده گرفته می شود. با این حال، یک اسکن فقط فهرست می تواند محتویات ستون های غیرکلیدی را بدون نیاز به بازدید از جدول فهرست بازگرداند، زیرا آنها مستقیماً از ورودی فهرست در دسترس هستند. بنابراین، افزودن ستون های غیرکلیدی اجازه می دهد از اسکن های فقط فهرست برای پرس وجوهایی استفاده شود که در غیر این صورت نمی توانستند از آنها استفاده کنند.

عاقلانه است که در مورد اضافه کردن ستون های غیر کلید به یک فهرست ، به ویژه ستون های گسترده ، محافظه کار باشید. اگر یک Tuple شاخص از حداکثر اندازه مجاز برای نوع شاخص فراتر رود ، درج داده ها شکست می خورند. در هر صورت ، ستونهای غیر کلید داده ها را از جدول فهرست کپی می کنند و اندازه شاخص را نفخ می کنند ، بنابراین به طور بالقوه جستجوها را کاهش می دهند. علاوه بر این ، فداکاری درخت B هرگز با فهرست هایی که دارای ستون غیر کلید هستند استفاده نمی شود.

ستون های ذکر شده در بند شامل کلاس های اپراتور مناسب نیستند. این بند می تواند شامل ستون هایی باشد که انواع داده های آنها دارای کلاس های اپراتور برای یک روش دسترسی معین نیستند.

عبارات به عنوان ستون های شامل پشتیبانی نمی شوند زیرا نمی توانند در اسکن های فقط شاخص استفاده شوند.

در حال حاضر ، روشهای دسترسی به شاخص B-Tree ، Gist و SP-Gist از این ویژگی پشتیبانی می کنند. در این شاخص ها ، مقادیر ستونهای ذکر شده در بند شامل موجود در برگهای برگ که مربوط به توپل های پشته است ، درج شده است ، اما در ورودی های سطح بالایی که برای ناوبری درخت استفاده می شود ، گنجانده نشده است.

نام فهرست ایجاد شده است. هیچ نام طرحواره ای نمی تواند در اینجا گنجانده شود. این شاخص همیشه در همان طرح مانند جدول والدین آن ایجاد می شود. نام فهرست باید از نام هر رابطه دیگری (جدول ، دنباله ، فهرست ، نمای ، نمای مادی یا جدول خارجی) در آن طرح متمایز باشد. اگر نام حذف شده باشد ، PostgreSQL نام مناسب را بر اساس نام جدول والدین و نام (های) ستون فهرست بندی شده انتخاب می کند.

در صورت تقسیم جدول ، نشانگر ایجاد شاخص ها در پارتیشن ها نیست. پیش فرض این است که دوباره انجام شود.

نام (احتمالاً SCHEMA واجد شرایط) از جدول که باید نمایه شود.

نام روش شاخص مورد استفاده. انتخاب ها BTREE ، HASH ، GIST ، SPGIST ، GIN ، BRIN یا روش های دسترسی به کاربر نصب شده مانند Bloom هستند. روش پیش فرض BTREE است.

نام ستون جدول.

عبارتی مبتنی بر یک یا چند ستون از جدول. همانطور که در نحو نشان داده شده است ، این عبارت معمولاً باید با پرانتز اطراف نوشته شود. با این حال ، اگر این عبارت دارای فرم تماس عملکردی باشد ، پرانتزها را می توان حذف کرد.

نام جمع آوری برای استفاده برای شاخص. به طور پیش فرض ، این شاخص از جمع آوری اعلام شده برای فهرست بندی ستون یا جمع آوری نتیجه ای که باید فهرست شود استفاده می کند. ایندکس ها با مجموعه های غیر پیش فرض می توانند برای نمایش داده هایی که شامل عبارات با استفاده از مجموعه های غیر پیش فرض هستند ، مفید باشد.

نام کلاس اپراتور. برای جزئیات بیشتر به زیر مراجعه کنید.

نام یک پارامتر کلاس اپراتور. برای جزئیات بیشتر به زیر مراجعه کنید.

ترتیب مرتب سازی صعودی (که پیش فرض است) را مشخص می کند.

ترتیب مرتب سازی نزولی را مشخص می کند.

مشخص می کند که null ها قبل از غیر تهی مرتب شوند. زمانی که DESC مشخص شده است این حالت پیش فرض است.

مشخص می کند که null ها بعد از غیر تهی مرتب شوند. این پیش فرض زمانی است که DESC مشخص نشده باشد.

NULLS DISTINCT NULLS NOT DISTINCT

مشخص می کند که آیا برای یک شاخص منحصر به فرد، مقادیر تهی باید متمایز (نه برابر) در نظر گرفته شوند. پیش فرض این است که آنها متمایز هستند، به طوری که یک شاخص منحصر به فرد می تواند چندین مقدار تهی در یک ستون داشته باشد.

نام یک پارامتر ذخیره سازی مختص روش شاخص. برای جزئیات بیشتر به پارامترهای ذخیره سازی فهرست زیر مراجعه کنید.

فضای جدولی که در آن فهرست ایجاد می شود. اگر مشخص نشده باشد، default_tablespace یا temp_tablespace برای نمایه ها در جداول موقت استفاده می شود.

بیان محدودیت برای یک شاخص جزئی.

پارامترهای ذخیره سازی شاخص

عبارت اختیاری WITH پارامترهای ذخیره سازی را برای ایندکس مشخص می کند. هر روش شاخص مجموعه ای از پارامترهای مجاز ذخیره سازی خود را دارد. متدهای شاخص B-tree، hash، GiST و SP-GiST همگی این پارامتر را می پذیرند:

پرکننده (عدد صحیح)

فاکتور fill برای یک ایندکس درصدی است که تعیین می کند روش ایندکس تا چه اندازه کامل صفحات فهرست را بسته بندی می کند. برای درختان B، صفحات برگ به این درصد در طول ساخت های اولیه شاخص پر می شوند، و همچنین هنگام گسترش شاخص در سمت راست (افزودن بزرگترین مقادیر کلیدی جدید). اگر صفحات متعاقباً کاملاً پر شوند، تقسیم می شوند و منجر به تکه تکه شدن ساختار فهرست روی دیسک می شود. B-trees از یک fillfactor پیش فرض 90 استفاده می کنند، اما هر مقدار صحیح از 10 تا 100 را می توان انتخاب کرد.

شاخص های درخت B در جداولی که در آن ها درج ها و/یا به روزرسانی های زیادی پیش بینی می شود، می توانند در زمان ایجاد INDEX (پس از بارگذاری انبوه در جدول) از تنظیمات فاکتور پرکننده کمتر بهره ببرند. مقادیر در محدوده 50 تا 90 می توانند به طور مفیدی میزان تقسیم صفحات را در طول عمر اولیه شاخص B-tree "هموار کنند" (کاهش ضریب پرکننده مانند این ممکن است حتی تعداد مطلق تقسیم صفحه را کاهش دهد، اگرچه این اثر حجم کار بسیار زیادی دارد. وابسته). تکنیک حذف شاخص پایین به بالا درخت B که در بخش 67. 4. 2 توضیح داده شده است به داشتن فضای «اضافی» در صفحات برای ذخیره نسخه های «اضافی» چندگانه وابسته است و بنابراین می تواند تحت تأثیر فاکتور پرکننده قرار گیرد (اگرچه تأثیر معمولاً قابل توجه نیست.).

در موارد خاص دیگر ممکن است افزایش FillFactor به 100 در زمان ایجاد شاخص به عنوان راهی برای به حداکثر رساندن استفاده از فضا مفید باشد. شما فقط باید این موضوع را در نظر بگیرید که کاملاً مطمئن باشید که جدول استاتیک است (یعنی اینکه هرگز تحت تأثیر قرار دادن یا به روزرسانی قرار نمی گیرد). تنظیم Fillfactor از 100 در غیر این صورت خطر عملکرد آسیب رساندن را دارد: حتی چند به روزرسانی یا درج باعث ایجاد سیل ناگهانی شکاف صفحه می شود.

روش های شاخص دیگر از FillFactor به روش های مختلف اما تقریباً مشابه استفاده می کنند. Fillfactor پیش فرض بین روش ها متفاوت است.

شاخص های درخت B علاوه بر این این پارامتر را می پذیرند:

deduplication_items (بولی)

کنترل استفاده از تکنیک Deduplication B-Tree که در بخش 67. 4. 3 شرح داده شده است. برای فعال یا غیرفعال کردن بهینه سازی ، روی یا خاموش تنظیم کنید.(هجی های جایگزین روشن و خاموش همانطور که در بخش 20. 1 شرح داده شده مجاز است.) پیش فرض روشن است.

توجه داشته باشید

خاموش کردن deduplication_items از طریق alter index مانع از درج های آینده در ایجاد فداکاری می شود ، اما به خودی خود باعث نمی شود که لیست ارسال های موجود در لیست های ارسال شده از بازنمایی استاندارد Tuple استفاده کند.

شاخص های GIST علاوه بر این این پارامتر را می پذیرند:

بافر (enum)

تعیین می کند که آیا تکنیک ساخت بافر شرح داده شده در بخش 68. 4. 1 برای ساخت شاخص استفاده می شود. با استفاده از بافر خاموش ، با آن فعال می شود ، و با استفاده از اتومبیل در ابتدا غیرفعال است ، اما پس از رسیدن اندازه شاخص به موثر_Cache_Size ، روشن می شود. پیش فرض خودکار است. توجه داشته باشید که اگر ساخت مرتب سازی شده امکان پذیر باشد ، به جای ساخت بافر استفاده می شود مگر اینکه بافر = روشن مشخص شود.

شاخص های جین پارامترهای مختلفی را می پذیرند:

Fastupdate (بولی)

این تنظیم استفاده از تکنیک به روزرسانی سریع را که در بخش 70. 4. 1 شرح داده شده است ، کنترل می کند. این یک پارامتر بولی است: به روزرسانی سریع ، خاموش آن را غیرفعال می کند. پیش فرض روشن است.

توجه داشته باشید

خاموش کردن FastUpdate از طریق alter index مانع از ورود در آینده در لیست ورودی های شاخص در انتظار می شود ، اما به خودی خود ورودی های قبلی را نمی کند. ممکن است بخواهید جدول را خلاء کنید یا بعد از آن با عملکرد GIN_CLEAN_PENDING_LIST تماس بگیرید تا از خالی شدن لیست در انتظار اطمینان حاصل کنید.

gin_pending_list_limit (عدد صحیح)

پارامتر Gin_Pending_List_Limit سفارشی. این مقدار در کیلوبایت مشخص شده است.

شاخص های برین پارامترهای مختلفی را می پذیرند:

pages_per_range (عدد صحیح)

تعداد بلوک های جدول را که برای هر ورودی یک فهرست برین یک محدوده بلوک را تشکیل می دهد ، تعریف می کند (برای اطلاعات بیشتر به بخش 71. 1 مراجعه کنید). پیش فرض 128 است.

تعریف می کند که آیا یک اجرای خلاصه برای محدوده صفحه قبلی هر زمان که درج در قسمت بعدی تشخیص داده شود ، صف می شود. برای اطلاعات بیشتر به بخش 71. 1. 1 مراجعه کنید. پیش فرض خاموش است.

شاخص های ساختمان همزمان

ایجاد یک فهرست می تواند در عملکرد منظم یک پایگاه داده دخالت کند. به طور معمول PostgreSQL جدول را برای فهرست بندی در برابر نوشتن قفل می کند و کل ساخت شاخص را با یک اسکن واحد از جدول انجام می دهد. معاملات دیگر هنوز هم می توانند جدول را بخوانند ، اما اگر سعی کنند ردیف های موجود در جدول را وارد ، به روز یا حذف کنند ، تا زمانی که ساخت شاخص به پایان برسد ، مسدود می شوند. اگر سیستم یک پایگاه داده تولید زنده باشد ، می تواند تأثیر شدیدی داشته باشد. جداول بسیار بزرگ می تواند ساعتها طول بکشد تا فهرست بندی شوند ، و حتی برای جداول کوچکتر ، یک فهرست ساخت می تواند نویسندگان را برای دوره هایی که غیرقابل قبول برای یک سیستم تولید هستند ، قفل کند.

PostgreSQL بدون قفل کردن نوشتن از شاخص های ساختمان پشتیبانی می کند. این روش با مشخص کردن گزینه همزمان ایجاد فهرست ایجاد می شود. هنگامی که از این گزینه استفاده می شود ، PostgreSQL باید دو اسکن از جدول را انجام دهد ، و علاوه بر این باید منتظر تمام معاملات موجود باشد که به طور بالقوه می توانند برای خاتمه دادن به این شاخص تغییر یا استفاده کنند. بنابراین این روش به کل کار بیشتری نسبت به یک شاخص استاندارد نیاز دارد و برای تکمیل آن به طور قابل توجهی بیشتر طول می کشد. با این حال ، از آنجا که اجازه می دهد تا در حالی که شاخص ساخته شده است ، عملیات عادی ادامه یابد ، این روش برای افزودن شاخص های جدید در یک محیط تولید مفید است. البته CPU اضافی و بار I/O اعمال شده توسط ایجاد شاخص ممکن است سایر عملیات را کند کند.

در یک شاخص همزمان ، این شاخص در واقع به عنوان یک شاخص "نامعتبر" در کاتالوگ های سیستم در یک معامله وارد می شود ، سپس دو اسکن جدول در دو معاملات دیگر رخ می دهد. قبل از هر اسکن جدول ، ساخت شاخص باید منتظر معاملات موجود باشد که جدول را اصلاح کرده اند تا خاتمه یابد. پس از اسکن دوم ، ساخت شاخص باید منتظر هرگونه معاملات که دارای عکس فوری است (به فصل 13 مراجعه کنید) که اسکن دوم را برای خاتمه دادن پیش بینی می کند ، از جمله معاملات استفاده شده توسط هر مرحله از شاخص همزمان بر روی جداول دیگر ، اگر شاخص های درگیر هستند یا جزئی هستند. ستون هایی داشته باشید که منابع ستون ساده ای نیستند. سپس سرانجام این شاخص را می توان "معتبر" و آماده برای استفاده مشخص کرد و دستور ایجاد شاخص خاتمه می یابد. با این حال ، حتی در این صورت ، این شاخص ممکن است بلافاصله برای نمایش داده ها قابل استفاده نباشد: در بدترین حالت ، نمی توان از آن استفاده کرد تا زمانی که معاملات وجود داشته باشد که پیش بینی شروع ساخت شاخص باشد.

اگر هنگام اسکن جدول ، مانند بن بست یا نقض منحصر به فرد در یک شاخص منحصر به فرد ، مشکلی پیش بیاید ، دستور ایجاد شاخص شکست خواهد خورد اما یک شاخص "نامعتبر" را پشت سر می گذارد. این شاخص برای اهداف پرس و جو نادیده گرفته می شود زیرا ممکن است ناقص باشد. با این حال هنوز هم به روزرسانی سربار را مصرف می کند. دستور psql d چنین شاخصی را نامعتبر گزارش می کند:

Postgres =#  D جدول جدول "Public. Tab" ستون |نوع |COLLATION |قابل برگشت |پیش فرض --------+---------+-----------+----------+-------- سرهنگ |عدد صحیح |||ایندکس ها: "idx" btree (col) نامعتبر است

روش بازیابی توصیه شده در چنین مواردی ، رها کردن شاخص و تلاش مجدد برای انجام همزمان ایجاد شاخص است.(احتمال دیگر بازسازی شاخص با شاخص Reindex به طور همزمان).

احتیاط دیگر هنگام ساختن یک شاخص منحصر به فرد به طور همزمان این است که با شروع اسکن جدول دوم ، محدودیت منحصر به فرد در مقابل سایر معاملات اجرا می شود. این بدان معناست که نقض محدودیت می تواند در سایر سؤالات قبل از در دسترس بودن شاخص برای استفاده ، یا حتی در مواردی که ساخت شاخص در نهایت شکست می خورد ، گزارش شود. همچنین ، اگر یک شکست در اسکن دوم رخ دهد ، شاخص "نامعتبر" همچنان محدودیت منحصر به فرد خود را پس از آن اجرا می کند.

ساختهای همزمان از شاخص های بیان و شاخص های جزئی پشتیبانی می شوند. خطاهایی که در ارزیابی این عبارات رخ می دهد می تواند باعث ایجاد رفتاری مشابه با آنچه در بالا برای نقض محدودیت منحصر به فرد توضیح داده شد ، ایجاد شود.

ساخت شاخص های منظم اجازه می دهد تا سایر شاخص های معمولی در همان جدول به طور همزمان اتفاق بیفتند ، اما فقط یک ساختار همزمان می تواند در یک زمان روی یک جدول رخ دهد. در هر صورت ، اصلاح شمای جدول در هنگام ساخت شاخص مجاز نیست. تفاوت دیگر این است که می توان یک دستور به طور منظم ایجاد شاخص را در یک بلوک معامله انجام داد ، اما ایجاد شاخص همزمان نمی تواند.

در حال حاضر ساختهای همزمان برای شاخص ها در جداول تقسیم شده پشتیبانی نمی شوند. با این حال ، شما ممکن است همزمان این شاخص را در هر پارتیشن به صورت جداگانه بسازید و سپس در نهایت شاخص تقسیم شده را بطور غیر متعارف ایجاد کنید تا زمانی که در جدول تقسیم شده می نویسد کاهش یابد. در این حالت ، ساختن شاخص تقسیم شده فقط یک عملیات ابرداده است.

یادداشت

برای کسب اطلاعات در مورد زمان استفاده از فهرست ، در هنگام استفاده از آنها ، به فصل 11 مراجعه کنید و در کدام موقعیت های خاص می توانند مفید باشند.

در حال حاضر ، فقط روش های B-Tree ، Gist ، Gin و Brin Index از شاخص های رنگی چند کلید پشتیبانی می کنند. اینکه آیا چندین ستون کلیدی وجود دارد ، مستقل از اینکه آیا ستون ها را می توان به فهرست اضافه کرد ، مستقل است. ایندکس ها می توانند حداکثر 32 ستون داشته باشند ، از جمله شامل ستون ها.(این حد می تواند هنگام ساخت PostgresQL تغییر یابد.) فقط B-Tree در حال حاضر از شاخص های منحصر به فرد پشتیبانی می کند.

یک کلاس اپراتور با پارامترهای اختیاری را می توان برای هر ستون از یک فهرست مشخص کرد. کلاس اپراتور اپراتورهایی را که توسط شاخص برای آن ستون استفاده می شود ، مشخص می کند. به عنوان مثال ، یک شاخص درخت B در عدد صحیح چهار بایت از کلاس INT4_OPS استفاده می کند. این کلاس اپراتور شامل توابع مقایسه برای اعداد صحیح چهار بایت است. در عمل کلاس اپراتور پیش فرض برای نوع داده ستون معمولاً کافی است. نکته اصلی داشتن کلاسهای اپراتور این است که برای برخی از انواع داده ها ، بیش از یک سفارش معنی دار وجود دارد. به عنوان مثال ، ما ممکن است بخواهیم یک نوع داده با شماره پیچیده را با ارزش مطلق یا قسمت واقعی مرتب کنیم. ما می توانیم این کار را با تعریف دو کلاس اپراتور برای نوع داده و سپس انتخاب کلاس مناسب هنگام ایجاد یک شاخص انجام دهیم. اطلاعات بیشتر در مورد کلاسهای اپراتور در بخش 11. 10 و در بخش 38. 16 است.

هنگامی که ایجاد شاخص در یک جدول تقسیم شده فراخوانی می شود ، رفتار پیش فرض این است که به همه پارتیشن ها بپردازید تا اطمینان حاصل شود که همه آنها دارای شاخص های مطابق هستند. هر پارتیشن ابتدا بررسی می شود تا مشخص شود که آیا یک شاخص معادل در حال حاضر وجود دارد ، و اگر چنین است ، این شاخص به عنوان یک شاخص پارتیشن به شاخص ایجاد شده وصل می شود ، که به شاخص والدین آن تبدیل می شود. اگر شاخص تطبیق وجود نداشته باشد ، شاخص جدیدی ایجاد می شود و به طور خودکار پیوست می شود. نام شاخص جدید در هر پارتیشن مشخص می شود که گویی هیچ نام فهرست در دستور مشخص نشده است. اگر تنها گزینه مشخص شود ، هیچ تلاشی انجام نمی شود و شاخص نامعتبر است.(alter index. پیوست پارتیشن شاخص معتبر است ، هنگامی که همه پارتیشن ها شاخص های تطبیق را بدست می آورند.) توجه داشته باشید که هر پارتیشن که در آینده با استفاده از جدول ایجاد ایجاد می شود. پارتیشن ویل بدون توجه به اینکه فقط مشخص شده است ، به طور خودکار یک شاخص تطبیق دارد.

برای روش های شاخص که از اسکن های سفارش داده شده پشتیبانی می کنند (در حال حاضر ، فقط درخت B) ، بندهای اختیاری ASC ، نزولی ، اول و/یا تهی آخرین را می توان برای اصلاح ترتیب مرتب سازی فهرست مشخص کرد. از آنجا که یک شاخص سفارش داده شده می تواند به صورت رو به جلو یا عقب اسکن شود ، ایجاد یک شاخص DESC تک ستونی به طور معمول مفید نیست-که سفارش مرتب سازی در حال حاضر با یک شاخص معمولی در دسترس است. مقدار این گزینه ها این است که می توان شاخص های چند رنگ را ایجاد کرد که مطابق با مرتب سازی مرتب شده توسط یک پرس و جو نظم مختلط ، مانند SELECT باشد. سفارش توسط x asc ، y desc. گزینه های NULS در صورت نیاز به پشتیبانی از رفتار "NULLS SORT LOW" ، به جای پیش فرض "NULLS SORT HIGH" ، در سؤالاتی که به فهرست ها بستگی دارد ، برای جلوگیری از مرتب سازی مراحل ، مفید هستند.

این سیستم به طور مرتب آماری را در تمام ستون های جدول جمع می کند. شاخص های غیر بیان تازه ایجاد شده می توانند بلافاصله از این آمار برای تعیین سودمندی یک شاخص استفاده کنند. برای شاخص های بیان جدید ، لازم است تجزیه و تحلیل یا انتظار برای تجزیه و تحلیل Daemon Autovacuum برای تجزیه و تحلیل جدول برای تولید آماری برای این شاخص ها.

برای اکثر روشهای شاخص ، سرعت ایجاد یک شاخص به تنظیم Maintenance_work_mem بستگی دارد. مقادیر بزرگتر باعث کاهش زمان مورد نیاز برای ایجاد شاخص می شود ، تا زمانی که شما آن را بزرگتر از مقدار حافظه واقعاً در دسترس قرار ندهید ، و این باعث می شود دستگاه به تعویض تبدیل شود.

PostgreSQL می تواند ضمن استفاده از چندین CPU به منظور پردازش سریعتر ردیف های جدول ، شاخص ها را بسازد. این ویژگی به عنوان ساخت شاخص موازی شناخته می شود. برای روشهای شاخص که از شاخص های ساختمان به طور موازی پشتیبانی می کنند (در حال حاضر ، فقط درخت B) ، Maintenance_work_mem حداکثر مقدار حافظه را که می تواند توسط هر یک از عملکردهای ساخت و ساز به عنوان یک کل استفاده شود ، صرف نظر از اینکه چند فرآیند کارگران شروع شده است ، مشخص می کند. به طور کلی ، یک مدل هزینه به طور خودکار تعیین می کند که در صورت وجود تعداد زیادی از فرآیندهای کارگر باید درخواست شود.

ساخت شاخص موازی ممکن است از افزایش Maintenance_Work_MEM بهره مند شود که در آن یک شاخص سریال معادل ایجاد کننده سود کم و یا فایده ای نخواهد داشت. توجه داشته باشید که maintenance_work_mem ممکن است بر تعداد فرآیندهای کارگران درخواست شده تأثیر بگذارد ، زیرا کارگران موازی باید حداقل سهم 32 مگابایتی از بودجه کل تعمیر و نگهداری_میم را داشته باشند. همچنین باید سهم 32 مگابایت باقی مانده برای روند رهبر وجود داشته باشد. افزایش MAX_PAPALLALL_MAINTANSIONS_ORKERS ممکن است امکان استفاده بیشتر از کارگران را فراهم کند ، که باعث می شود زمان مورد نیاز برای ایجاد شاخص کاهش یابد ، تا زمانی که ساخت شاخص در حال حاضر I/O محدود نشده باشد. البته باید ظرفیت CPU کافی نیز وجود داشته باشد که در غیر این صورت بیکار باشد.

تنظیم یک مقدار برای موازی_ کارگران از طریق جدول Alter به طور مستقیم کنترل می کند که تعداد زیادی از فرآیندهای کارگر موازی توسط یک شاخص ایجاد در برابر جدول درخواست می شود. این مدل هزینه را به طور کامل دور می کند و از تأثیرگذاری بر میزان درخواست کارگران موازی جلوگیری می کند. تنظیم موازی_ کارگران به 0 از طریق جدول Alter ، در همه موارد ، شاخص موازی روی جدول را غیرفعال می کند.

نکته

ممکن است بخواهید پس از تنظیم آن به عنوان بخشی از تنظیم یک فهرست ، کارگران موازی_ را مجدداً تنظیم کنید. این امر از تغییرات ناخواسته در برنامه های پرس و جو جلوگیری می کند ، زیرا موازی ها بر روی اسکن جدول موازی تأثیر می گذارد.

در حالی که ایجاد شاخص با گزینه همزمان از ساختهای موازی بدون محدودیت های خاص پشتیبانی می کند ، فقط اسکن جدول اول در واقع به صورت موازی انجام می شود.

برای حذف یک فهرست از شاخص قطره استفاده کنید.

مانند هر معامله طولانی مدت ، ایجاد شاخص روی یک جدول می تواند تأثیر بگذارد که با استفاده از خلاء همزمان در هر جدول دیگر ، می توان Tuples را حذف کرد.

نسخه های قبلی PostgreSQL نیز دارای روش شاخص R-Tree بود. این روش حذف شده است زیرا مزایای قابل توجهی نسبت به روش GIST ندارد. اگر استفاده از RTREE مشخص شده است ، ایجاد شاخص آن را به عنوان با استفاده از GIST ، برای ساده سازی تبدیل پایگاه داده های قدیمی به GIST تفسیر می کند.

هر شاخص در حال اجرا در حال اجرا ، پیشرفت خود را در نمای PG_STAT_PROGRESS_CREATE_INDEX گزارش می کند. برای جزئیات بیشتر به بخش 28. 4. 2 مراجعه کنید.

مثال ها

برای ایجاد یک فهرست منحصر به فرد B-Tree در عنوان ستون در فیلم های جدول:

ایجاد فهرست منحصر به فرد عنوان_IDX در فیلم ها (عنوان) ؛

برای ایجاد یک شاخص منحصر به فرد B-Tree در عنوان ستون با کارگردان ستون های شامل و رتبه بندی در فیلم های جدول:

ایجاد فهرست منحصر به فرد عنوان_idx در فیلم ها (عنوان) شامل (کارگردان ، رتبه بندی) ؛

برای ایجاد یک شاخص B-Tree با Deduplication غیرفعال:

ایجاد عنوان index title_idx در فیلم ها (عنوان) با (deduplication_items = خاموش) ؛

برای ایجاد یک شاخص در بیان پایین (عنوان) ، امکان جستجوهای حساس به موارد را فراهم می کند:

ایجاد فهرست در فیلم ها ((پایین (عنوان))) ؛

(در این مثال ما تصمیم گرفته ایم تا نام فهرست را حذف کنیم ، بنابراین سیستم یک نام را انتخاب می کند ، به طور معمول films_lower_idx.)

برای ایجاد یک فهرست با جمع غیر پیش فرض:

ایجاد عنوان index_idx_german در فیلم ها (عنوان جمع "de_de") ؛

برای ایجاد یک فهرست با مرتب سازی مرتب سازی غیر پیش فرض از تهی:

ایجاد عنوان index_idx_nulls_low در فیلم ها (عنوان اول Nulls) ؛

برای ایجاد یک شاخص با فاکتور پر کردن غیر پیش فرض:

ایجاد فهرست منحصر به فرد عنوان_idx در فیلم ها (عنوان) با (fillFactor = 70) ؛

برای ایجاد شاخص جین با به روزرسانی های سریع غیرفعال:

ایجاد index gin_idx را در اسناد_ت با استفاده از جین (مکان) با (fastupdate = خاموش) ایجاد کنید.

برای ایجاد یک فهرست در کد ستون در فیلم های جدول و داشتن فهرست در Tablespace IndexSpace:

ایجاد index code_idx در فیلم ها (کد) TableSpace IndexSpace ؛

برای ایجاد یک شاخص GIST در یک ویژگی نقطه به گونه ای که بتوانیم از اپراتورهای جعبه در نتیجه عملکرد تبدیل استفاده کنیم:

ایجاد فهرست PointLoc در نقاط با استفاده از GIST (جعبه (مکان ، مکان)).* را از نقاطی که کادر (مکان ، مکان) && '(0،0) ، (1،1)' :: کادر انتخاب کنید.

برای ایجاد یک شاخص بدون قفل کردن در جدول:

ایجاد شاخص همزمان sales_quantity_index در sales_table (مقدار) ؛

سازگاری

ایجاد فهرست یک پسوند زبان postgreSQL است. در استاندارد SQL هیچ ماده ای برای شاخص ها وجود ندارد.

همچنین ببینید

تصحیح

اگر در اسناد و مدارک صحیح مشاهده می کنید ، تجربه شما را با ویژگی خاص مطابقت ندارد یا نیاز به توضیح بیشتر دارد ، لطفاً از این فرم برای گزارش یک موضوع مستند استفاده کنید.

کپی رایت © 1996-2023 گروه توسعه جهانی PostgreSQL