🔵 عنوان مقاله
A SQL Heuristic: ORs Are Expensive (10 minute read)
🟢 خلاصه مقاله:
OR در SQL اغلب باعث کندی میشود، چون بسیاری از query plannerها برای OR بین ستونهای مختلف به sequential scan یا index merge/bitmap OR متوسل میشوند، در حالیکه AND بهطور طبیعی با compound indexها جور است. یک راه مؤثر، بازنویسی OR به چند کوئریِ ایندکسپسند و ترکیب آنها با UNION/UNION ALL است تا هر شاخه از ایندکس مناسب خود استفاده کند و زمان اجرا گاهی تا ۱۰۰ برابر کاهش یابد. راهحل پایدارتر، بازطراحی schema با extension tables است تا بهجای OR روی چند خاصیتِ پراکنده، با JOIN به جدولهای باریک و ایندکسشده دسترسی پیدا کنید. همیشه با EXPLAIN/EXPLAIN ANALYZE اندازهگیری کنید؛ در جداول کوچک یا OR روی یک ستون (مشابه IN) شاید مشکل نداشته باشید، اما بهطور کلی: AND را با compound index هماهنگ کنید، از OR بین ستونها بپرهیزید، در صورت لزوم از UNION بهره ببرید و برای مسیرهای پرتردد، بازطراحی schema را در نظر بگیرید.
#SQL #DatabasePerformance #QueryOptimization #Indexes #PostgreSQL #MySQL #DataModeling #EXPLAIN
🟣لینک مقاله:
https://ethanseal.com/articles/ors-are-expensive?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
A SQL Heuristic: ORs Are Expensive (10 minute read)
🟢 خلاصه مقاله:
OR در SQL اغلب باعث کندی میشود، چون بسیاری از query plannerها برای OR بین ستونهای مختلف به sequential scan یا index merge/bitmap OR متوسل میشوند، در حالیکه AND بهطور طبیعی با compound indexها جور است. یک راه مؤثر، بازنویسی OR به چند کوئریِ ایندکسپسند و ترکیب آنها با UNION/UNION ALL است تا هر شاخه از ایندکس مناسب خود استفاده کند و زمان اجرا گاهی تا ۱۰۰ برابر کاهش یابد. راهحل پایدارتر، بازطراحی schema با extension tables است تا بهجای OR روی چند خاصیتِ پراکنده، با JOIN به جدولهای باریک و ایندکسشده دسترسی پیدا کنید. همیشه با EXPLAIN/EXPLAIN ANALYZE اندازهگیری کنید؛ در جداول کوچک یا OR روی یک ستون (مشابه IN) شاید مشکل نداشته باشید، اما بهطور کلی: AND را با compound index هماهنگ کنید، از OR بین ستونها بپرهیزید، در صورت لزوم از UNION بهره ببرید و برای مسیرهای پرتردد، بازطراحی schema را در نظر بگیرید.
#SQL #DatabasePerformance #QueryOptimization #Indexes #PostgreSQL #MySQL #DataModeling #EXPLAIN
🟣لینک مقاله:
https://ethanseal.com/articles/ors-are-expensive?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
The Benefits of a DESCending Index
🟢 خلاصه مقاله:
گذشته از کاربرد شناختهشدهی DESC در همخوانسازی ایندکس با ORDER BYهای ترکیبی، در برخی سناریوهای خاص یک ایندکسِ نزولی میتواند هنگام ساخت و درج، فضای کمتری اشغال کند. وقتی الگوی درج دادهها با جهت مرتبسازی ایندکس همراستا باشد، احتمال شکاف صفحه کمتر میشود و چیدمان برگها فشردهتر میماند؛ نتیجه میتواند ایندکسی کوچکتر و با محلیّت حافظه بهتر باشد.
از نظر اجرا هم مزیتی وجود دارد: برای تولید همان ترتیب نتایج، یک اسکن روبهجلو روی ایندکسِ نزولی معمولاً از اسکن روبهعقب روی ایندکسِ صعودی کاراتر است، چون با پیشخوانی دیسک و الگوهای کش سازگارتر است. بنابراین برای پرسوجوهای «جدیدترینها اول» مثل ORDER BY created_at DESC همراه با LIMIT، انتخاب ایندکس نزولی اغلب اجرای پایدارتر و سریعتری میدهد. جمعبندی: جهت ایندکس را بر اساس الگوی غالب ORDER BY انتخاب و هر دو حالت را با EXPLAIN روی دادههای واقعی بسنجید.
#PostgreSQL #Indexing #DESC #ORDERBY #QueryOptimization #DatabasePerformance #BTree #TopN
🟣لینک مقاله:
https://postgresweekly.com/link/176021/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Benefits of a DESCending Index
🟢 خلاصه مقاله:
گذشته از کاربرد شناختهشدهی DESC در همخوانسازی ایندکس با ORDER BYهای ترکیبی، در برخی سناریوهای خاص یک ایندکسِ نزولی میتواند هنگام ساخت و درج، فضای کمتری اشغال کند. وقتی الگوی درج دادهها با جهت مرتبسازی ایندکس همراستا باشد، احتمال شکاف صفحه کمتر میشود و چیدمان برگها فشردهتر میماند؛ نتیجه میتواند ایندکسی کوچکتر و با محلیّت حافظه بهتر باشد.
از نظر اجرا هم مزیتی وجود دارد: برای تولید همان ترتیب نتایج، یک اسکن روبهجلو روی ایندکسِ نزولی معمولاً از اسکن روبهعقب روی ایندکسِ صعودی کاراتر است، چون با پیشخوانی دیسک و الگوهای کش سازگارتر است. بنابراین برای پرسوجوهای «جدیدترینها اول» مثل ORDER BY created_at DESC همراه با LIMIT، انتخاب ایندکس نزولی اغلب اجرای پایدارتر و سریعتری میدهد. جمعبندی: جهت ایندکس را بر اساس الگوی غالب ORDER BY انتخاب و هر دو حالت را با EXPLAIN روی دادههای واقعی بسنجید.
#PostgreSQL #Indexing #DESC #ORDERBY #QueryOptimization #DatabasePerformance #BTree #TopN
🟣لینک مقاله:
https://postgresweekly.com/link/176021/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
CYBERTEC PostgreSQL | Services & Support
Benefits of a DESCending index
The DESC clause in CREATE INDEX is rarely needed. I'll show use cases for descending indexes, including storage efficiency and performance.
🔵 عنوان مقاله
pg_qualstats: Extension for Collecting Statistics About Predicates
🟢 خلاصه مقاله:
pg_qualstats یک افزونه برای PostgreSQL است که آمار مربوط به استفاده از گزارهها در WHERE و JOIN را جمعآوری میکند تا نشان دهد کدام فیلترها در عمل بیشترین استفاده و بیشترین اثر را دارند. این دادهها به شما کمک میکند برای بار کاری واقعی خود، ایندکسهای هدفمند (تکی، ترکیبی، جزئی یا بر اساس عبارت) طراحی کنید و با کاهش I/O و تأخیر، کارایی را بهبود دهید. میتوانید نتایج را مستقیم از نماهای افزونه ببینید یا از طریق POWA (Postgres Workload Analyzer) آنها را تحلیل و اولویتبندی کنید. در کنار ابزاری مثل pg_stat_statements، این افزونه مشخص میکند کدام بخش از یک کوئری پرهزینه است و در نتیجه یافتن ایندکسهای از دسترفته و ارزیابی اثربخشی ایندکسهای جدید سادهتر میشود.
#PostgreSQL #pg_qualstats #POWA #PostgresWorkloadAnalyzer #QueryOptimization #Indexing #DatabasePerformance
🟣لینک مقاله:
https://postgresweekly.com/link/175733/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pg_qualstats: Extension for Collecting Statistics About Predicates
🟢 خلاصه مقاله:
pg_qualstats یک افزونه برای PostgreSQL است که آمار مربوط به استفاده از گزارهها در WHERE و JOIN را جمعآوری میکند تا نشان دهد کدام فیلترها در عمل بیشترین استفاده و بیشترین اثر را دارند. این دادهها به شما کمک میکند برای بار کاری واقعی خود، ایندکسهای هدفمند (تکی، ترکیبی، جزئی یا بر اساس عبارت) طراحی کنید و با کاهش I/O و تأخیر، کارایی را بهبود دهید. میتوانید نتایج را مستقیم از نماهای افزونه ببینید یا از طریق POWA (Postgres Workload Analyzer) آنها را تحلیل و اولویتبندی کنید. در کنار ابزاری مثل pg_stat_statements، این افزونه مشخص میکند کدام بخش از یک کوئری پرهزینه است و در نتیجه یافتن ایندکسهای از دسترفته و ارزیابی اثربخشی ایندکسهای جدید سادهتر میشود.
#PostgreSQL #pg_qualstats #POWA #PostgresWorkloadAnalyzer #QueryOptimization #Indexing #DatabasePerformance
🟣لینک مقاله:
https://postgresweekly.com/link/175733/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - powa-team/pg_qualstats: A PostgreSQL extension for collecting statistics about predicates, helping find what indices are…
A PostgreSQL extension for collecting statistics about predicates, helping find what indices are missing - powa-team/pg_qualstats
🔵 عنوان مقاله
What Do Postgres 18's New 'Index Searches' Lines in EXPLAIN Mean?
🟢 خلاصه مقاله:
در Postgres 18 خط جدیدی به خروجی EXPLAIN ANALYZE اضافه شده به نام Index Searches که تعداد «پروبهای منطقی» به ایندکس را در طول اجرای هر نود نشان میدهد. این شمارنده با تعداد ردیفهای تولیدشده فرق دارد: ممکن است یک جستوجوی ایندکسی دهها یا صدها ردیف برگرداند (مثلاً در یک رِنج اسکن)، یا برعکس، تعداد زیادی جستوجو انجام شود اما خروجی کمی تولید شود.
این خط در نودهای مرتبط با ایندکس مثل Index Scan، Index Only Scan و Bitmap Index Scan دیده میشود و در طرحهای پارامتری (مثلاً Nested Loop با Index Scan در سمت داخلی) بسیار کمککننده است؛ معمولاً برای هر ردیفِ سمت بیرونی، یک Index Search ثبت میشود. اگر تعداد Index Searches بالا و خروجی کم باشد، احتمال تکرار پروبهای غیرکارا وجود دارد و شاید بهتر باشد استراتژی جوین (مثلاً Hash Join)، طراحی ایندکسهای ترکیبی یا خود عبارتهای شرطی را بازنگری کنید.
برای تیونینگ، عدد Index Searches را در کنار rows و زمانبندیها مقایسه کنید تا «هزینه هر پروب» و «انتخابپذیری» را بهتر بفهمید. توجه کنید که این شاخص نشاندهنده پروبهای منطقی است و مستقیماً بیانگر I/O فیزیکی نیست. همچنین در طرحهای موازی بهصورت هر-ورتکر/نود گزارش میشود و فقط با EXPLAIN ANALYZE در دسترس است. در مجموع، این قابلیت جدید دید دقیقتری از الگوهای دسترسی ایندکس، تناسب ایندکس و انتخاب استراتژی جوین به شما میدهد.
#Postgres #PostgreSQL18 #EXPLAINANALYZE #Indexing #QueryOptimization #DatabasePerformance #IndexScan
🟣لینک مقاله:
https://postgresweekly.com/link/176988/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
What Do Postgres 18's New 'Index Searches' Lines in EXPLAIN Mean?
🟢 خلاصه مقاله:
در Postgres 18 خط جدیدی به خروجی EXPLAIN ANALYZE اضافه شده به نام Index Searches که تعداد «پروبهای منطقی» به ایندکس را در طول اجرای هر نود نشان میدهد. این شمارنده با تعداد ردیفهای تولیدشده فرق دارد: ممکن است یک جستوجوی ایندکسی دهها یا صدها ردیف برگرداند (مثلاً در یک رِنج اسکن)، یا برعکس، تعداد زیادی جستوجو انجام شود اما خروجی کمی تولید شود.
این خط در نودهای مرتبط با ایندکس مثل Index Scan، Index Only Scan و Bitmap Index Scan دیده میشود و در طرحهای پارامتری (مثلاً Nested Loop با Index Scan در سمت داخلی) بسیار کمککننده است؛ معمولاً برای هر ردیفِ سمت بیرونی، یک Index Search ثبت میشود. اگر تعداد Index Searches بالا و خروجی کم باشد، احتمال تکرار پروبهای غیرکارا وجود دارد و شاید بهتر باشد استراتژی جوین (مثلاً Hash Join)، طراحی ایندکسهای ترکیبی یا خود عبارتهای شرطی را بازنگری کنید.
برای تیونینگ، عدد Index Searches را در کنار rows و زمانبندیها مقایسه کنید تا «هزینه هر پروب» و «انتخابپذیری» را بهتر بفهمید. توجه کنید که این شاخص نشاندهنده پروبهای منطقی است و مستقیماً بیانگر I/O فیزیکی نیست. همچنین در طرحهای موازی بهصورت هر-ورتکر/نود گزارش میشود و فقط با EXPLAIN ANALYZE در دسترس است. در مجموع، این قابلیت جدید دید دقیقتری از الگوهای دسترسی ایندکس، تناسب ایندکس و انتخاب استراتژی جوین به شما میدهد.
#Postgres #PostgreSQL18 #EXPLAINANALYZE #Indexing #QueryOptimization #DatabasePerformance #IndexScan
🟣لینک مقاله:
https://postgresweekly.com/link/176988/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pgMustard
What do the new Index Searches lines in EXPLAIN mean? - pgMustard
In Postgres 18 you’ll now see “Index Searches” lines in EXPLAIN ANALYZE output. If like me you were wondering what those mean exactly, you’re in the right place.