نکات و ترفندهای SQL برای بهینه سازی عملکرد دیتابیس شما.
#SQL #Database #Optimization #Performance #TipsAndTricks
https://github.com/ben-n93/SQL-tips-and-tricks
➖➖➖➖➖➖➖➖
👑 @Database_Academy
#SQL #Database #Optimization #Performance #TipsAndTricks
https://github.com/ben-n93/SQL-tips-and-tricks
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔥1
🔵 عنوان مقاله
Getting Excited About Postgres 18
🟢 خلاصه مقاله:
Postgres 18 تا یک هفته دیگر نهایی میشود و مهمترین ویژگی تازهاش asynchronous I/O است؛ قابلیتی که امکان انجام عملیات خواندن/نوشتن بدون مسدود کردن مسیر اجرای اصلی را میدهد و در بسیاری از سناریوها باعث افزایش توان عملیاتی و کاهش تأخیر میشود. این تغییر برای بارهای کاری پرتراکنش، سیستمهای ترکیبی OLTP/تحلیلی و پردازشهای سنگین I/O نوید عملکرد روانتر و پایدارتر را میدهد. با انتشار نسخه نهایی، انتظار میرود راهنماها و بهترینعملها برای بهرهگیری از این بهبودها ارائه شود و تیمها بتوانند با تنظیمات مناسب، از جهش عملکردی Postgres 18 بهره ببرند.
#Postgres18 #Postgres #PostgreSQL #AsynchronousIO #Database #Performance #OpenSource
🟣لینک مقاله:
https://postgresweekly.com/link/174461/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Getting Excited About Postgres 18
🟢 خلاصه مقاله:
Postgres 18 تا یک هفته دیگر نهایی میشود و مهمترین ویژگی تازهاش asynchronous I/O است؛ قابلیتی که امکان انجام عملیات خواندن/نوشتن بدون مسدود کردن مسیر اجرای اصلی را میدهد و در بسیاری از سناریوها باعث افزایش توان عملیاتی و کاهش تأخیر میشود. این تغییر برای بارهای کاری پرتراکنش، سیستمهای ترکیبی OLTP/تحلیلی و پردازشهای سنگین I/O نوید عملکرد روانتر و پایدارتر را میدهد. با انتشار نسخه نهایی، انتظار میرود راهنماها و بهترینعملها برای بهرهگیری از این بهبودها ارائه شود و تیمها بتوانند با تنظیمات مناسب، از جهش عملکردی Postgres 18 بهره ببرند.
#Postgres18 #Postgres #PostgreSQL #AsynchronousIO #Database #Performance #OpenSource
🟣لینک مقاله:
https://postgresweekly.com/link/174461/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Get Excited About Postgres 18 | Crunchy Data Blog
New to Postgres 18, features like asynchronous i/o, uuid v7, b-tree skip scans, and virtual generated columns.
❤1
🔵 عنوان مقاله
Understanding WAL and Optimizing It with a Dedicated Disk
🟢 خلاصه مقاله:
WAL روشی کلیدی برای پایداری و ریکاوری پس از کرش است: تغییرات ابتدا به شکل ترتیبی در یک لاگ نوشته و بهصورت پایدار flush میشوند و سپس در صورت نیاز روی دادههای اصلی اعمال یا بازپخش میگردند. گلوگاه اصلی معمولاً همان fsync/flush است که باید دوام را تضمین کند. وقتی WAL روی همان دیسکی باشد که فایلهای داده نیز روی آن I/O تصادفی انجام میدهند، وقفه و رقابت صف موجب جهش در تاخیر بهویژه در p99/p999 میشود. قرار دادن WAL روی یک دیسک اختصاصی این مسیر حساس را ایزوله میکند، الگوی نوشتن ترتیبی را حفظ میکند و تاخیر را قابل پیشبینیتر و بهرهوری را بیشتر میسازد.
در عمل میتوان از یک NVMe مستقل یا یک ولوم ابری جداگانه استفاده کرد؛ فایلسیستمهای رایج مانند ext4 یا XFS با تنظیمات ساده و بدون سربار اضافی مناسباند و باید اطمینان داشت که semantics مربوط به write barrier و cache flush مطابق نیازهای دوام هستند. از منظر Golang، بهینهسازی WAL معمولاً با سگمنتبندی و پیشاختصاص فایلها، نوشتن همتراز با بلوک، checksum، batch کردن درخواستها، group commit با آستانه زمانی/حجمی، استفاده سنجیده از O_DSYNC/fdatasync و مدیریت دقیق بافر انجام میشود. اندازهگیری دقیق قبل و بعد (میانگین و p99 fsync، نرخ نوشتن، و زمان انتهابهانتها) مشخص میکند آیا دیسک اختصاصی هزینهاش را جبران میکند یا خیر؛ برای بارهای نوشتاری بالا یا SLA سختگیرانه، این ایزولاسیون معمولاً ارزشمند است.
#WAL #Golang #Databases #Performance #Storage #NVMe #SystemsDesign
🟣لینک مقاله:
https://postgresweekly.com/link/174762/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Understanding WAL and Optimizing It with a Dedicated Disk
🟢 خلاصه مقاله:
WAL روشی کلیدی برای پایداری و ریکاوری پس از کرش است: تغییرات ابتدا به شکل ترتیبی در یک لاگ نوشته و بهصورت پایدار flush میشوند و سپس در صورت نیاز روی دادههای اصلی اعمال یا بازپخش میگردند. گلوگاه اصلی معمولاً همان fsync/flush است که باید دوام را تضمین کند. وقتی WAL روی همان دیسکی باشد که فایلهای داده نیز روی آن I/O تصادفی انجام میدهند، وقفه و رقابت صف موجب جهش در تاخیر بهویژه در p99/p999 میشود. قرار دادن WAL روی یک دیسک اختصاصی این مسیر حساس را ایزوله میکند، الگوی نوشتن ترتیبی را حفظ میکند و تاخیر را قابل پیشبینیتر و بهرهوری را بیشتر میسازد.
در عمل میتوان از یک NVMe مستقل یا یک ولوم ابری جداگانه استفاده کرد؛ فایلسیستمهای رایج مانند ext4 یا XFS با تنظیمات ساده و بدون سربار اضافی مناسباند و باید اطمینان داشت که semantics مربوط به write barrier و cache flush مطابق نیازهای دوام هستند. از منظر Golang، بهینهسازی WAL معمولاً با سگمنتبندی و پیشاختصاص فایلها، نوشتن همتراز با بلوک، checksum، batch کردن درخواستها، group commit با آستانه زمانی/حجمی، استفاده سنجیده از O_DSYNC/fdatasync و مدیریت دقیق بافر انجام میشود. اندازهگیری دقیق قبل و بعد (میانگین و p99 fsync، نرخ نوشتن، و زمان انتهابهانتها) مشخص میکند آیا دیسک اختصاصی هزینهاش را جبران میکند یا خیر؛ برای بارهای نوشتاری بالا یا SLA سختگیرانه، این ایزولاسیون معمولاً ارزشمند است.
#WAL #Golang #Databases #Performance #Storage #NVMe #SystemsDesign
🟣لینک مقاله:
https://postgresweekly.com/link/174762/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Stormatics
PostgreSQL WAL: Boost Performance with a Dedicated Disk
Learn how to speed up PostgreSQL by moving WAL to its own disk. Cut I/O contention and improve write performance safely.
❤1
🔵 عنوان مقاله
Going Down the Rabbit Hole of Postgres 18 Features
🟢 خلاصه مقاله:
**این مطلب با حفظ شور انتشار اخیر Postgres 18، بهجای ارجاع مستقیم به یادداشتهای طولانی انتشار، مرور قابلفهمی از ویژگیهای جدید ارائه میدهد. Tudor تغییرات مهم و بهبودهای عملی را در قالبی موضوعمحور توضیح میدهد تا روشن شود هر قابلیت چه مسئلهای را حل میکند و در چه سناریوهایی سودمند است. تمرکز متن بر فهم ساده، مقایسه با نسخههای قبلی و اشاره به نکات سازگاری و برنامهریزی برای ارتقاست. خروجی، یک نقشه راه عملی برای تیمهاست تا سریعتر تصمیم بگیرند کدام قابلیتها را همین حالا بیازمایند و کدام را بعداً ارزیابی کنند.
#Postgres18 #PostgreSQL #Database #ReleaseNotes #OpenSource #SQL #DBA #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175084/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Going Down the Rabbit Hole of Postgres 18 Features
🟢 خلاصه مقاله:
**این مطلب با حفظ شور انتشار اخیر Postgres 18، بهجای ارجاع مستقیم به یادداشتهای طولانی انتشار، مرور قابلفهمی از ویژگیهای جدید ارائه میدهد. Tudor تغییرات مهم و بهبودهای عملی را در قالبی موضوعمحور توضیح میدهد تا روشن شود هر قابلیت چه مسئلهای را حل میکند و در چه سناریوهایی سودمند است. تمرکز متن بر فهم ساده، مقایسه با نسخههای قبلی و اشاره به نکات سازگاری و برنامهریزی برای ارتقاست. خروجی، یک نقشه راه عملی برای تیمهاست تا سریعتر تصمیم بگیرند کدام قابلیتها را همین حالا بیازمایند و کدام را بعداً ارزیابی کنند.
#Postgres18 #PostgreSQL #Database #ReleaseNotes #OpenSource #SQL #DBA #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175084/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Xata
Going down the rabbit hole of Postgres 18 features by Tudor Golubenco
A comprehensive list of PostgreSQL 18 new features, performance optimizations, operational and observability improvements, and new tools for devs.
🔵 عنوان مقاله
a visual explainer of processes and threads
🟢 خلاصه مقاله:
** این مقاله با یک توضیح تصویری، تفاوتهای بنیادین بین فرآیند و رشته را توضیح میدهد: فرآیندها فضای حافظهای جدا دارند و ارتباطشان از طریق مکانیزمهای سیستمعامل انجام میشود، در حالیکه رشتهها داخل یک فرآیند حافظه مشترک دارند، ارتباطشان سریعتر است اما ریسک تداخل و خرابی گستردهتر میشود. سپس این دیدگاه به معماری پایگاههای داده تعمیم داده میشود: Postgres از مدل process-per-connection با فرآیندهای جداگانه برای هر اتصال و حافظه مشترک برای هماهنگی استفاده میکند؛ MySQL در یک mysqld واحد با مدل thread-per-connection (یا thread pool) و رشتههای متعدد اجرا میشود. نتیجه مقایسه: Postgres ایزولاسیون قویتری در سطح حافظه دارد اما سربار هر اتصال بیشتر است و خرابی یک backend میتواند به بازراهاندازی برای حفظ سازگاری منجر شود؛ MySQL از نظر حافظه برای اتصالات زیاد بهینهتر و تعویض متن در آن سریعتر است، ولی خطا یا ازدحام در یک رشته میتواند کل فرایند را متاثر کند و نیازمند تنظیم دقیق برای جلوگیری از رقابت قفلهاست. در عمل، هر دو با ابزارهای connection pooling مانند PgBouncer و ProxySQL افراطها را تعدیل میکنند و انتخاب نهایی به اولویتهای بارکاری بین ایزولاسیون/قابلیت مشاهده در برابر بازده و مقیاسپذیری اتصال بستگی دارد.
#OperatingSystems #Concurrency #Postgres #MySQL #DatabaseArchitecture #Threads #Processes #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/174753/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
a visual explainer of processes and threads
🟢 خلاصه مقاله:
** این مقاله با یک توضیح تصویری، تفاوتهای بنیادین بین فرآیند و رشته را توضیح میدهد: فرآیندها فضای حافظهای جدا دارند و ارتباطشان از طریق مکانیزمهای سیستمعامل انجام میشود، در حالیکه رشتهها داخل یک فرآیند حافظه مشترک دارند، ارتباطشان سریعتر است اما ریسک تداخل و خرابی گستردهتر میشود. سپس این دیدگاه به معماری پایگاههای داده تعمیم داده میشود: Postgres از مدل process-per-connection با فرآیندهای جداگانه برای هر اتصال و حافظه مشترک برای هماهنگی استفاده میکند؛ MySQL در یک mysqld واحد با مدل thread-per-connection (یا thread pool) و رشتههای متعدد اجرا میشود. نتیجه مقایسه: Postgres ایزولاسیون قویتری در سطح حافظه دارد اما سربار هر اتصال بیشتر است و خرابی یک backend میتواند به بازراهاندازی برای حفظ سازگاری منجر شود؛ MySQL از نظر حافظه برای اتصالات زیاد بهینهتر و تعویض متن در آن سریعتر است، ولی خطا یا ازدحام در یک رشته میتواند کل فرایند را متاثر کند و نیازمند تنظیم دقیق برای جلوگیری از رقابت قفلهاست. در عمل، هر دو با ابزارهای connection pooling مانند PgBouncer و ProxySQL افراطها را تعدیل میکنند و انتخاب نهایی به اولویتهای بارکاری بین ایزولاسیون/قابلیت مشاهده در برابر بازده و مقیاسپذیری اتصال بستگی دارد.
#OperatingSystems #Concurrency #Postgres #MySQL #DatabaseArchitecture #Threads #Processes #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/174753/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
Processes and Threads — PlanetScale
Processes and threads are fundamental abstrations for operating systems. Learn how they work and how they impact database performance in this interactive article.
🔵 عنوان مقاله
How I Learned to Use wal_inspect
🟢 خلاصه مقاله:
این نوشته روایت یادگیری کار با pg_walinspect برای خواندن و فهمیدن رفتار write-ahead log در PostgreSQL است. نویسنده نشان میدهد چطور میتوان با کوئری گرفتن از WAL در بازههای مشخص LSN، الگوی فعالیت سیستم را دید: از نقش checkpointها و full-page writeها تا اثر autovacuum، split شدن ایندکسها، بارگذاریهای حجیم و منشأ افزایش I/O. مزیت pg_walinspect این است که داخل دیتابیس و با SQL میشود دادهها را خلاصه و فیلتر کرد و با زمان و متریکهای مانیتورینگ تطبیق داد، بدون خروج به ابزارهای بیرونی.
رویکرد پیشنهادی این است: بازه زمانی/LSN را محدود کنید، ابتدا خلاصهها را ببینید و سپس در صورت نیاز به جزئیات بروید؛ هنگام عیبیابی، روی resource managerهای مرتبط تمرکز کنید و الگوهای WAL را با لاگها و نمایههای آماری مثل pg_stat همراستا کنید. محدودیت اصلی این است که محتوای سطرها را نمیبینید و فقط به فراداده دسترسی دارید، اما همین برای ساختن و آزمودن فرضیهها کافی است. در نتیجه، pg_walinspect ابزار کمهزینه و امنی برای بهبود observability، کاهش زمان رفع اشکال و فهم عمیقتر رفتار PostgreSQL محسوب میشود.
#PostgreSQL #WAL #pg_walinspect #DatabaseInternals #Observability #Performance #Replication
🟣لینک مقاله:
https://postgresweekly.com/link/175096/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How I Learned to Use wal_inspect
🟢 خلاصه مقاله:
این نوشته روایت یادگیری کار با pg_walinspect برای خواندن و فهمیدن رفتار write-ahead log در PostgreSQL است. نویسنده نشان میدهد چطور میتوان با کوئری گرفتن از WAL در بازههای مشخص LSN، الگوی فعالیت سیستم را دید: از نقش checkpointها و full-page writeها تا اثر autovacuum، split شدن ایندکسها، بارگذاریهای حجیم و منشأ افزایش I/O. مزیت pg_walinspect این است که داخل دیتابیس و با SQL میشود دادهها را خلاصه و فیلتر کرد و با زمان و متریکهای مانیتورینگ تطبیق داد، بدون خروج به ابزارهای بیرونی.
رویکرد پیشنهادی این است: بازه زمانی/LSN را محدود کنید، ابتدا خلاصهها را ببینید و سپس در صورت نیاز به جزئیات بروید؛ هنگام عیبیابی، روی resource managerهای مرتبط تمرکز کنید و الگوهای WAL را با لاگها و نمایههای آماری مثل pg_stat همراستا کنید. محدودیت اصلی این است که محتوای سطرها را نمیبینید و فقط به فراداده دسترسی دارید، اما همین برای ساختن و آزمودن فرضیهها کافی است. در نتیجه، pg_walinspect ابزار کمهزینه و امنی برای بهبود observability، کاهش زمان رفع اشکال و فهم عمیقتر رفتار PostgreSQL محسوب میشود.
#PostgreSQL #WAL #pg_walinspect #DatabaseInternals #Observability #Performance #Replication
🟣لینک مقاله:
https://postgresweekly.com/link/175096/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The World of Data
How I learned to use wal_inspect
It has been a while since last time I blogged about any real-life mysteries I resolved. Here is one which I am really happy about, because it took a while and it was not obvious. Before that, I did…
🔵 عنوان مقاله
PostgreSQL R2DBC Driver 1.1
🟢 خلاصه مقاله:
PostgreSQL R2DBC Driver 1.1 دسترسی Reactive و غیرمسدودکننده به PostgreSQL را برای برنامههای Java فراهم میکند. با تکیه بر R2DBC و پشتیبانی از backpressure، اجرای کوئریها و استریم نتایج بهصورت asynchronous انجام میشود و زیر بار بالا کارایی و بهرهوری منابع بهبود مییابد. این درایور با Project Reactor، Spring WebFlux و Spring Data R2DBC یکپارچه است و اجازه میدهد کل مسیر از HTTP تا دیتابیس Reactive باقی بماند و قابلیتهایی مثل ترکیب، لغو و مدیریت جریانها را فراهم میکند. نسخه 1.1 بر بلوغ و پایداری تمرکز دارد و با بهبود همخوانی با R2DBC SPI و بهینهسازی رفتار تحت فشار، برای استفاده تولیدی مناسبتر شده است. اگر معماری شما Reactive است یا به همزمانی بالا و استریم داده نیاز دارید، این درایور انتخاب مناسبی است؛ در سناریوهای ساده و مسدودکننده، JDBC همچنان میتواند گزینهای عملی باشد.
#PostgreSQL #R2DBC #Java #SpringWebFlux #ReactiveProgramming #NonBlocking #Databases #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175405/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgreSQL R2DBC Driver 1.1
🟢 خلاصه مقاله:
PostgreSQL R2DBC Driver 1.1 دسترسی Reactive و غیرمسدودکننده به PostgreSQL را برای برنامههای Java فراهم میکند. با تکیه بر R2DBC و پشتیبانی از backpressure، اجرای کوئریها و استریم نتایج بهصورت asynchronous انجام میشود و زیر بار بالا کارایی و بهرهوری منابع بهبود مییابد. این درایور با Project Reactor، Spring WebFlux و Spring Data R2DBC یکپارچه است و اجازه میدهد کل مسیر از HTTP تا دیتابیس Reactive باقی بماند و قابلیتهایی مثل ترکیب، لغو و مدیریت جریانها را فراهم میکند. نسخه 1.1 بر بلوغ و پایداری تمرکز دارد و با بهبود همخوانی با R2DBC SPI و بهینهسازی رفتار تحت فشار، برای استفاده تولیدی مناسبتر شده است. اگر معماری شما Reactive است یا به همزمانی بالا و استریم داده نیاز دارید، این درایور انتخاب مناسبی است؛ در سناریوهای ساده و مسدودکننده، JDBC همچنان میتواند گزینهای عملی باشد.
#PostgreSQL #R2DBC #Java #SpringWebFlux #ReactiveProgramming #NonBlocking #Databases #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175405/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
Release v1.1.0.RELEASE · pgjdbc/r2dbc-postgresql
⭐ New Features
Expose API to subscribe to Postgres notice messages #570
Add codecs for DayOfWeek, Month, MonthDay, Period, Year, YearMonth #591
Make CodecMetadata.getDataTypes() more flexible #600...
Expose API to subscribe to Postgres notice messages #570
Add codecs for DayOfWeek, Month, MonthDay, Period, Year, YearMonth #591
Make CodecMetadata.getDataTypes() more flexible #600...
🔵 عنوان مقاله
Postgres 18 Released
🟢 خلاصه مقاله:
Postgres 18 طبق برنامه منتشر شد. این نسخه جهش انقلابی نیست، اما مجموعهای از بهبودهای هدفمند ارائه میدهد که در عمل به اجرای سریعتر کوئریها، استفاده مؤثرتر از ایندکسها، I/O کارآمدتر و نگهداری سبکتر (VACUUM/autovacuum) منجر میشود. بهینهسازیهای تکرار و بازیابی نیز پایداری و توان عملیاتی را برای سناریوهای High Availability بهتر میکنند. علاوه بر این، گزینههای پیکربندی و پایش شفافتر و سختگیریهای امنیتی تازه، مدیریت و تیونینگ را سادهتر میسازد. برای ارتقا، یادداشتهای نسخه را بررسی کنید، سازگاری اکستنشنها را بسنجید و روی محیط Stage با بار کاری واقعی تست بگیرید.
#Postgres #PostgreSQL #Database #Performance #Release #SQL #OpenSource #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/174773/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres 18 Released
🟢 خلاصه مقاله:
Postgres 18 طبق برنامه منتشر شد. این نسخه جهش انقلابی نیست، اما مجموعهای از بهبودهای هدفمند ارائه میدهد که در عمل به اجرای سریعتر کوئریها، استفاده مؤثرتر از ایندکسها، I/O کارآمدتر و نگهداری سبکتر (VACUUM/autovacuum) منجر میشود. بهینهسازیهای تکرار و بازیابی نیز پایداری و توان عملیاتی را برای سناریوهای High Availability بهتر میکنند. علاوه بر این، گزینههای پیکربندی و پایش شفافتر و سختگیریهای امنیتی تازه، مدیریت و تیونینگ را سادهتر میسازد. برای ارتقا، یادداشتهای نسخه را بررسی کنید، سازگاری اکستنشنها را بسنجید و روی محیط Stage با بار کاری واقعی تست بگیرید.
#Postgres #PostgreSQL #Database #Performance #Release #SQL #OpenSource #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/174773/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgreSQL News
PostgreSQL 18 Released!
The [PostgreSQL Global Development Group](https://www.postgresql.org) today announced the release of [PostgreSQL 18](https://www.postgresql.org/docs/18/release-18.html), the latest version of the world's most advanced …
🔵 عنوان مقاله
date and timestamp versions of random(min, max)
🟢 خلاصه مقاله:
این مقاله به دو بهروزرسانی کاربردی اشاره میکند: افزودهشدن نسخههای مبتنیبر نوعهای date و timestamp برای تابع random(min, max) و نمایش برآوردهای برنامهریز برای گره Memoize در خروجی EXPLAIN. با پشتیبانی جدید random(min, max)، میتوان مقادیر تصادفی از نوع تاریخ یا زمان را مستقیماً در یک بازه مشخص تولید کرد؛ کاری مفید برای تولید دادهی آزمایشی، شبیهسازی بار کاری و ناشناسسازی دادههای زمانی بدون نیاز به تبدیلهای اضافی. همچنین، EXPLAIN اکنون برآوردهای مربوط به Memoize را نشان میدهد تا روشنتر شود چرا برنامهریز از این گره استفاده کرده و تأثیر تخمینی کش و هزینهها چیست؛ موضوعی که به عیبیابی و بهینهسازی پرسوجوها کمک میکند.
#Databases #SQL #EXPLAIN #Memoize #Random #Date #Timestamp #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175090/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
date and timestamp versions of random(min, max)
🟢 خلاصه مقاله:
این مقاله به دو بهروزرسانی کاربردی اشاره میکند: افزودهشدن نسخههای مبتنیبر نوعهای date و timestamp برای تابع random(min, max) و نمایش برآوردهای برنامهریز برای گره Memoize در خروجی EXPLAIN. با پشتیبانی جدید random(min, max)، میتوان مقادیر تصادفی از نوع تاریخ یا زمان را مستقیماً در یک بازه مشخص تولید کرد؛ کاری مفید برای تولید دادهی آزمایشی، شبیهسازی بار کاری و ناشناسسازی دادههای زمانی بدون نیاز به تبدیلهای اضافی. همچنین، EXPLAIN اکنون برآوردهای مربوط به Memoize را نشان میدهد تا روشنتر شود چرا برنامهریز از این گره استفاده کرده و تأثیر تخمینی کش و هزینهها چیست؛ موضوعی که به عیبیابی و بهینهسازی پرسوجوها کمک میکند.
#Databases #SQL #EXPLAIN #Memoize #Random #Date #Timestamp #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175090/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
👍1
🔵 عنوان مقاله
Key Operational Enhancements and Integration Options in Postgres 16
🟢 خلاصه مقاله:
این مطلب با تمرکز بر مخاطبان Golang Weekly توضیح میدهد که Postgres 16 چه بهبودهایی برای عملیات روزمره و یکپارچهسازی با سرویسها آورده است. نویسنده روی حوزههای عملی مثل کارایی پایدارتر تحت بار، رفتار بهتر autovacuum، و رصدپذیری دقیقتر برای IO و پردازههای پسزمینه تأکید میکند تا تنظیمات و عیبیابی سریعتر و مطمئنتر انجام شود. همچنین به ارتقاهای مرتبط با replication منطقی و سنککردن ایمنتر، مدیریت slotها و سناریوهای failover اشاره میکند تا پیادهسازیهای HA و چندمنطقهای سادهتر شوند. در بخش یکپارچهسازی، گزینههای Go مانند pgx و database/sql، مدیریت connection pooling با pgxpool یا PgBouncer، اتصال به سامانههای رویدادمحور از طریق logical decoding و ابزارهایی مثل Debezium، و الگوهای LISTEN/NOTIFY و FDW مرور میشود. جمعبندی مقاله: Postgres 16 دردسرهای عملیاتی را کمتر و ادغام با معماریهای متنوع را سادهتر میکند و یک چکلیست کوتاه برای ارزیابی و ارتقای امن ارائه میدهد.
#Postgres16 #PostgreSQL #Golang #Go #Database #Replication #Observability #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175401/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Key Operational Enhancements and Integration Options in Postgres 16
🟢 خلاصه مقاله:
این مطلب با تمرکز بر مخاطبان Golang Weekly توضیح میدهد که Postgres 16 چه بهبودهایی برای عملیات روزمره و یکپارچهسازی با سرویسها آورده است. نویسنده روی حوزههای عملی مثل کارایی پایدارتر تحت بار، رفتار بهتر autovacuum، و رصدپذیری دقیقتر برای IO و پردازههای پسزمینه تأکید میکند تا تنظیمات و عیبیابی سریعتر و مطمئنتر انجام شود. همچنین به ارتقاهای مرتبط با replication منطقی و سنککردن ایمنتر، مدیریت slotها و سناریوهای failover اشاره میکند تا پیادهسازیهای HA و چندمنطقهای سادهتر شوند. در بخش یکپارچهسازی، گزینههای Go مانند pgx و database/sql، مدیریت connection pooling با pgxpool یا PgBouncer، اتصال به سامانههای رویدادمحور از طریق logical decoding و ابزارهایی مثل Debezium، و الگوهای LISTEN/NOTIFY و FDW مرور میشود. جمعبندی مقاله: Postgres 16 دردسرهای عملیاتی را کمتر و ادغام با معماریهای متنوع را سادهتر میکند و یک چکلیست کوتاه برای ارزیابی و ارتقای امن ارائه میدهد.
#Postgres16 #PostgreSQL #Golang #Go #Database #Replication #Observability #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/175401/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Severalnines
Key Operational enhancements and integration options in PostgreSQL 16
Discover why PostgreSQL 16 remains a crucial step for teams with its improved query planner and operational advancements for databases.
🔵 عنوان مقاله
memoize planner estimates in EXPLAIN.
🟢 خلاصه مقاله:
**
این مطلب که در شماره اخیر Golang Weekly معرفی شده، درباره memoize کردن برآوردهای planner در EXPLAIN است تا تحلیل پرسوجوها سریعتر و قابلاتکاتر شود. ایده اصلی این است که تخمینهای میانی (مثل cardinality و هزینهها) بر اساس نسخه نرمالشدهی بخشهای پرسوجو و ورودیهای اثرگذار (آمار جداول، وضعیت schema، و تنظیمات planner) ذخیره شوند و در اجرایهای بعدی EXPLAIN دوباره استفاده شوند. نتیجه: کاهش هزینه محاسبات تکراری، ثبات بیشتر خروجیها، و مقایسه آسانتر تغییرات.
در پیادهسازی با Go میتوان با cacheهای سبک، هشکردن پرسوجوی نرمالشده و وضعیت کاتالوگ، و قلابهای ابطال (invalidation) قابلتنظیم به این هدف رسید؛ این رویکرد برای ابزارهای توسعه، CI و بنچمارکها سودمند است. البته چالشها هم مهماند: کهنگی دادههای cache با تغییر آمار یا تنظیمات، ضرورت سیاستهای ابطال شفاف، ترجیحاً cache کردن فقط برآوردها (نه کل plan)، ارائه نشانگرهای hit/miss در خروجی EXPLAIN، و تعیین دامنه و سقف اندازه cache (مثلاً در سطح session).
به طور خلاصه، memoize کردن برآوردهای planner در EXPLAIN چرخههای تحلیل را تسریع و نتایج را پایدارتر میکند، به شرط آنکه مرزهای cache و سیاستهای ابطال بهخوبی مدیریت شوند.
#Golang #Go #EXPLAIN #Database #QueryPlanner #Memoization #Performance #Optimization
🟣لینک مقاله:
https://postgresweekly.com/link/175091/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
memoize planner estimates in EXPLAIN.
🟢 خلاصه مقاله:
**
این مطلب که در شماره اخیر Golang Weekly معرفی شده، درباره memoize کردن برآوردهای planner در EXPLAIN است تا تحلیل پرسوجوها سریعتر و قابلاتکاتر شود. ایده اصلی این است که تخمینهای میانی (مثل cardinality و هزینهها) بر اساس نسخه نرمالشدهی بخشهای پرسوجو و ورودیهای اثرگذار (آمار جداول، وضعیت schema، و تنظیمات planner) ذخیره شوند و در اجرایهای بعدی EXPLAIN دوباره استفاده شوند. نتیجه: کاهش هزینه محاسبات تکراری، ثبات بیشتر خروجیها، و مقایسه آسانتر تغییرات.
در پیادهسازی با Go میتوان با cacheهای سبک، هشکردن پرسوجوی نرمالشده و وضعیت کاتالوگ، و قلابهای ابطال (invalidation) قابلتنظیم به این هدف رسید؛ این رویکرد برای ابزارهای توسعه، CI و بنچمارکها سودمند است. البته چالشها هم مهماند: کهنگی دادههای cache با تغییر آمار یا تنظیمات، ضرورت سیاستهای ابطال شفاف، ترجیحاً cache کردن فقط برآوردها (نه کل plan)، ارائه نشانگرهای hit/miss در خروجی EXPLAIN، و تعیین دامنه و سقف اندازه cache (مثلاً در سطح session).
به طور خلاصه، memoize کردن برآوردهای planner در EXPLAIN چرخههای تحلیل را تسریع و نتایج را پایدارتر میکند، به شرط آنکه مرزهای cache و سیاستهای ابطال بهخوبی مدیریت شوند.
#Golang #Go #EXPLAIN #Database #QueryPlanner #Memoization #Performance #Optimization
🟣لینک مقاله:
https://postgresweekly.com/link/175091/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
Exploring Postgres 18's New UUIDv7 Support
🟢 خلاصه مقاله:
** پشتیبانی از UUIDv7 در Postgres 18 شناسههایی یکتا، زمانمرتب و تقریباً یکنوا ایجاد میکند که بر خلاف UUIDv4، بر اساس زمان بهصورت واژگانی مرتب میشوند. این ویژگی باعث بهبود محلیّت در ایندکسهای B-tree، کاهش شکافت صفحات و بهبود کارایی درجهای پیاپی میشود و کوئریهایی مثل ORDER BY id DESC با LIMIT و محدودههای زمانی را سادهتر و سریعتر میکند. در عین حال، بهدلیل ترکیب زمان و تصادفیبودن، خطر نقاط داغ کاهش مییابد، هرچند در بارگذاریهای بسیار همزمان باید پایش شود و پایداری ساعت سیستم اهمیت دارد. مهاجرت از UUIDv4 آسان است؛ میتوان مقادیر قدیمی را حفظ کرد و تولید پیشفرض را برای رکوردهای جدید به UUIDv7 تغییر داد. برای اغلب لاگهای رویداد و بارهای شبهزمانمحور، UUIDv7 توازن خوبی میان یکتایی، کارایی و سادگی کوئری فراهم میکند.
#Postgres #PostgreSQL #UUIDv7 #UUID #Database #Performance #Indexing #TimeSeries
🟣لینک مقاله:
https://postgresweekly.com/link/175725/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Exploring Postgres 18's New UUIDv7 Support
🟢 خلاصه مقاله:
** پشتیبانی از UUIDv7 در Postgres 18 شناسههایی یکتا، زمانمرتب و تقریباً یکنوا ایجاد میکند که بر خلاف UUIDv4، بر اساس زمان بهصورت واژگانی مرتب میشوند. این ویژگی باعث بهبود محلیّت در ایندکسهای B-tree، کاهش شکافت صفحات و بهبود کارایی درجهای پیاپی میشود و کوئریهایی مثل ORDER BY id DESC با LIMIT و محدودههای زمانی را سادهتر و سریعتر میکند. در عین حال، بهدلیل ترکیب زمان و تصادفیبودن، خطر نقاط داغ کاهش مییابد، هرچند در بارگذاریهای بسیار همزمان باید پایش شود و پایداری ساعت سیستم اهمیت دارد. مهاجرت از UUIDv4 آسان است؛ میتوان مقادیر قدیمی را حفظ کرد و تولید پیشفرض را برای رکوردهای جدید به UUIDv7 تغییر داد. برای اغلب لاگهای رویداد و بارهای شبهزمانمحور، UUIDv7 توازن خوبی میان یکتایی، کارایی و سادگی کوئری فراهم میکند.
#Postgres #PostgreSQL #UUIDv7 #UUID #Database #Performance #Indexing #TimeSeries
🟣لینک مقاله:
https://postgresweekly.com/link/175725/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Aiven
Exploring PostgreSQL 18's new UUIDv7 support
Exploring what's interesting about UUIDv7 support using a demo crab store.
🔵 عنوان مقاله
PostGIS Performance: pg_stat_statements and Postgres Tuning
🟢 خلاصه مقاله:
**این مقاله نشان میدهد چطور با استفاده از PostGIS روی Postgres میتوان کارایی پرسوجوهای مکانی را بهبود داد. محور اصلی کار، اندازهگیری دقیق با pg_stat_statements برای شناسایی پرهزینهترین پرسوجوها و سپس تحلیل آنها با EXPLAIN/ANALYZE است. توصیههای کلیدی شامل انتخاب درست geometry یا geography، ساخت ایندکسهای GiST/SP-GiST، نوشتن شرطهای قابل استفاده توسط ایندکس (مثل ST_Intersects و محدودههای جعبهای)، و اجرای VACUUM/ANALYZE پس از بارگذاریهای حجیم است. در بخش تنظیمات Postgres هم به shared_buffers، effective_cache_size، work_mem، موازیسازی، تنظیمات autovacuum و در صورت نیاز پارتیشنبندی اشاره میشود. برای سرویسهای Go (به نقل از Golang Weekly)، استفاده از pooling مناسب، جلوگیری از الگوهای N+1، Batch کردن عملیات، بهرهگیری از COPY و تعیین statement_timeout توصیه شده است. رویکرد کلی: اندازهگیری، اعمال تغییرات هدفمند، و اعتبارسنجی مداوم برای رسیدن به کارایی پایدار و سریعتر.
#PostGIS #PostgreSQL #pg_stat_statements #DatabaseTuning #Geospatial #Golang #Performance #SQL
🟣لینک مقاله:
https://postgresweekly.com/link/176025/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostGIS Performance: pg_stat_statements and Postgres Tuning
🟢 خلاصه مقاله:
**این مقاله نشان میدهد چطور با استفاده از PostGIS روی Postgres میتوان کارایی پرسوجوهای مکانی را بهبود داد. محور اصلی کار، اندازهگیری دقیق با pg_stat_statements برای شناسایی پرهزینهترین پرسوجوها و سپس تحلیل آنها با EXPLAIN/ANALYZE است. توصیههای کلیدی شامل انتخاب درست geometry یا geography، ساخت ایندکسهای GiST/SP-GiST، نوشتن شرطهای قابل استفاده توسط ایندکس (مثل ST_Intersects و محدودههای جعبهای)، و اجرای VACUUM/ANALYZE پس از بارگذاریهای حجیم است. در بخش تنظیمات Postgres هم به shared_buffers، effective_cache_size، work_mem، موازیسازی، تنظیمات autovacuum و در صورت نیاز پارتیشنبندی اشاره میشود. برای سرویسهای Go (به نقل از Golang Weekly)، استفاده از pooling مناسب، جلوگیری از الگوهای N+1، Batch کردن عملیات، بهرهگیری از COPY و تعیین statement_timeout توصیه شده است. رویکرد کلی: اندازهگیری، اعمال تغییرات هدفمند، و اعتبارسنجی مداوم برای رسیدن به کارایی پایدار و سریعتر.
#PostGIS #PostgreSQL #pg_stat_statements #DatabaseTuning #Geospatial #Golang #Performance #SQL
🟣لینک مقاله:
https://postgresweekly.com/link/176025/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
PostGIS Performance: pg_stat_statements and Postgres tuning | Crunchy Data Blog
PostGIS performance basics. Second post in a series covering pg_stat_statements, shared buffers, work_mem, and parallel queries.
🔵 عنوان مقاله
Redis is Fast - I'll Cache in Postgres
🟢 خلاصه مقاله:
** این مقاله مقایسهای بین استفاده از Postgres و Redis برای کارهای کش ساده ارائه میکند و نتیجه میگیرد که هرچند Redis از نظر سرعت خام برتر است، در بسیاری از سناریوها این برتری آنقدر نیست که اضافهکردن یک سیستم جداگانه را توجیه کند. اگر دادههای پرتکرار در حافظه Postgres جا شوند و با یک جدول کلید-مقدار ساده (بههمراه expires_at و ایندکس مناسب)، prepared statements و connection pooling کار کنید، تأخیر بهحد کافی پایین و پایدار خواهد بود. زمانی Redis منطقی است که به تأخیر بسیار کم و QPS بسیار بالا نیاز دارید، کش مشترک بین سرویسها میخواهید، یا به قابلیتهای خاص آن مثل data structures، pub/sub و eviction policies نیاز دارید. در غیر این صورت، سادگی عملیاتی، هزینه کمتر و کاهش نقاط خرابی با استفاده از Postgres ارزشمندتر است؛ و در صورت آشکار شدن گلوگاه عملکردی، میتوان بعداً Redis را پشت یک رابط مناسب اضافه و بهتدریج مهاجرت کرد.
#Redis #Postgres #Caching #Performance #Databases #Architecture #DevOps #Scalability
🟣لینک مقاله:
https://postgresweekly.com/link/174758/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Redis is Fast - I'll Cache in Postgres
🟢 خلاصه مقاله:
** این مقاله مقایسهای بین استفاده از Postgres و Redis برای کارهای کش ساده ارائه میکند و نتیجه میگیرد که هرچند Redis از نظر سرعت خام برتر است، در بسیاری از سناریوها این برتری آنقدر نیست که اضافهکردن یک سیستم جداگانه را توجیه کند. اگر دادههای پرتکرار در حافظه Postgres جا شوند و با یک جدول کلید-مقدار ساده (بههمراه expires_at و ایندکس مناسب)، prepared statements و connection pooling کار کنید، تأخیر بهحد کافی پایین و پایدار خواهد بود. زمانی Redis منطقی است که به تأخیر بسیار کم و QPS بسیار بالا نیاز دارید، کش مشترک بین سرویسها میخواهید، یا به قابلیتهای خاص آن مثل data structures، pub/sub و eviction policies نیاز دارید. در غیر این صورت، سادگی عملیاتی، هزینه کمتر و کاهش نقاط خرابی با استفاده از Postgres ارزشمندتر است؛ و در صورت آشکار شدن گلوگاه عملکردی، میتوان بعداً Redis را پشت یک رابط مناسب اضافه و بهتدریج مهاجرت کرد.
#Redis #Postgres #Caching #Performance #Databases #Architecture #DevOps #Scalability
🟣لینک مقاله:
https://postgresweekly.com/link/174758/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Dizzy zone
Redis is fast - I'll cache in Postgres
There are books & many articles online, like this one arguing for using Postgres for everything. I thought I’d take a look at one use case - using Postgres instead of Redis for caching. I work with APIs quite a bit, so I’d build a super simple HTTP server…
🔵 عنوان مقاله
A SQL Query's Roadtrip Through Postgres
🟢 خلاصه مقاله:
این مطلب با الهام از توضیحات Jesús Espino و Umair Shahid نشان میدهد یک پرسوجوی SQL در Postgres چگونه از مرحله دریافت و parse، به planنویسی و سپس اجرا میرسد. Postgres با اتکا به optimizer مسیرهای دسترسی مناسب را انتخاب میکند و هنگام اجرا، دادهها را از طریق buffer manager به حافظه میآورد و با MVCC دید سازگار هر تراکنش را تضمین میکند. در مسیر نوشتن، ابتدا تغییرات در WAL ثبت میشوند و صفحات بهروزشده در حافظه به «dirty pages» تبدیل میگردند؛ یعنی نسخه درونحافظهای با نسخه روی دیسک تفاوت دارد. سپس background writer و checkpointer بهتدریج این صفحات را روی دیسک مینویسند تا پایداری داده و بازیابی سریع پس از خطا ممکن شود. تنظیماتی مثل shared_buffers و پارامترهای مربوط به checkpoint و WAL روی تأخیر، توان عملیاتی و الگوی I/O اثر مستقیم دارند. برای توسعهدهندگان، انتخاب شاخصهای مناسب، شکلدهی درست پرسوجوها و پایش با ابزارهایی مانند pg_stat_bgwriter و pg_buffercache به درک فشار نوشتن، نسبت صفحات dirty و کارایی حافظه کمک میکند.
#Postgres #SQL #DatabaseInternals #WAL #DirtyPages #QueryPlanner #Checkpoints #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/176686/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
A SQL Query's Roadtrip Through Postgres
🟢 خلاصه مقاله:
این مطلب با الهام از توضیحات Jesús Espino و Umair Shahid نشان میدهد یک پرسوجوی SQL در Postgres چگونه از مرحله دریافت و parse، به planنویسی و سپس اجرا میرسد. Postgres با اتکا به optimizer مسیرهای دسترسی مناسب را انتخاب میکند و هنگام اجرا، دادهها را از طریق buffer manager به حافظه میآورد و با MVCC دید سازگار هر تراکنش را تضمین میکند. در مسیر نوشتن، ابتدا تغییرات در WAL ثبت میشوند و صفحات بهروزشده در حافظه به «dirty pages» تبدیل میگردند؛ یعنی نسخه درونحافظهای با نسخه روی دیسک تفاوت دارد. سپس background writer و checkpointer بهتدریج این صفحات را روی دیسک مینویسند تا پایداری داده و بازیابی سریع پس از خطا ممکن شود. تنظیماتی مثل shared_buffers و پارامترهای مربوط به checkpoint و WAL روی تأخیر، توان عملیاتی و الگوی I/O اثر مستقیم دارند. برای توسعهدهندگان، انتخاب شاخصهای مناسب، شکلدهی درست پرسوجوها و پایش با ابزارهایی مانند pg_stat_bgwriter و pg_buffercache به درک فشار نوشتن، نسبت صفحات dirty و کارایی حافظه کمک میکند.
#Postgres #SQL #DatabaseInternals #WAL #DirtyPages #QueryPlanner #Checkpoints #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/176686/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Internals for Interns
Overview | Internals for Interns
Ever wonder what happens when you type SELECT * FROM users WHERE id = 42; and hit Enter? That simple query triggers a fascinating journey through PostgreSQL’s internals—a complex series of operations involving multiple processes, sophisticated memory management…
🔵 عنوان مقاله
pg_roaringbitmap 1.0: Roaring Bitmap Extension
🟢 خلاصه مقاله:
** نسخه ۱.۰ pg_roaringbitmap یک افزونه پایدار و آمادهبهکار برای PostgreSQL ارائه میکند که Roaring bitmaps را بهصورت بومی در پایگاهداده در دسترس میگذارد. Roaring bitmaps ساختارهایی فشرده و بهینه برای نمایش مجموعههای بزرگ از اعداد صحیح هستند که معمولاً در سرعت و مصرف حافظه از بیتمپهای فشرده مرسوم بهتر عمل میکنند، بهویژه در عملگرهایی مانند اجتماع، اشتراک و محاسبه کاردینالیتی.
این افزونه امکان ذخیرهسازی و پردازش مستقیم Roaring bitmaps در SQL را فراهم میکند؛ در نتیجه فیلترهای عضویت، پرسوجوهای تحلیلی و بارهای کاری بزرگ با حافظه و I/O کمتر و سرعت بیشتر اجرا میشوند. چنین قابلیتی برای تحلیل رویداد، تلهمتری، حوزههای ad-tech و ایندکسگذاری معکوس کاربرد ویژهای دارد و به تیمها کمک میکند بدون ترک پایگاهداده، از مزایای فشردهسازی و کارایی بالای Roaring bitmaps بهره ببرند.
#PostgreSQL #pg_roaringbitmap #RoaringBitmap #Database #Compression #Performance #Analytics
🟣لینک مقاله:
https://postgresweekly.com/link/176997/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pg_roaringbitmap 1.0: Roaring Bitmap Extension
🟢 خلاصه مقاله:
** نسخه ۱.۰ pg_roaringbitmap یک افزونه پایدار و آمادهبهکار برای PostgreSQL ارائه میکند که Roaring bitmaps را بهصورت بومی در پایگاهداده در دسترس میگذارد. Roaring bitmaps ساختارهایی فشرده و بهینه برای نمایش مجموعههای بزرگ از اعداد صحیح هستند که معمولاً در سرعت و مصرف حافظه از بیتمپهای فشرده مرسوم بهتر عمل میکنند، بهویژه در عملگرهایی مانند اجتماع، اشتراک و محاسبه کاردینالیتی.
این افزونه امکان ذخیرهسازی و پردازش مستقیم Roaring bitmaps در SQL را فراهم میکند؛ در نتیجه فیلترهای عضویت، پرسوجوهای تحلیلی و بارهای کاری بزرگ با حافظه و I/O کمتر و سرعت بیشتر اجرا میشوند. چنین قابلیتی برای تحلیل رویداد، تلهمتری، حوزههای ad-tech و ایندکسگذاری معکوس کاربرد ویژهای دارد و به تیمها کمک میکند بدون ترک پایگاهداده، از مزایای فشردهسازی و کارایی بالای Roaring bitmaps بهره ببرند.
#PostgreSQL #pg_roaringbitmap #RoaringBitmap #Database #Compression #Performance #Analytics
🟣لینک مقاله:
https://postgresweekly.com/link/176997/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - ChenHuajun/pg_roaringbitmap: RoaringBitmap extension for PostgreSQL
RoaringBitmap extension for PostgreSQL. Contribute to ChenHuajun/pg_roaringbitmap development by creating an account on GitHub.
🔵 عنوان مقاله
PostGIS Performance: Intersection Predicates and Overlays
🟢 خلاصه مقاله:
خلاصهای از یک نوشته در ادامهٔ مجموعهای برای بهبود کارایی PostGIS است که بر دو بخش کلیدی تمرکز دارد: «intersection predicates» مثل ST_Intersects، ST_Touches و ST_Contains و «overlay»ها مثل ST_Intersection و ST_Union. راهبرد اصلی این است: ابتدا با فیلتر سریع جعبهمحیطی (&& روی ایندکس GiST) تعداد کاندیداها را کم کنید و سپس رابطهٔ دقیق را با GEOS بررسی کنید. برای پرسوجوهای معمول، سادهترین predicate که نیازتان را پوشش میدهد انتخاب شود؛ از ST_Intersects برای joinهای اولیه استفاده و در صورت نیاز دقیقتر کنید. عملیات overlay چون هندسهٔ جدید میسازند، پرهزینهاند؛ فقط وقتی واقعاً خروجی هندسی لازم است سراغشان بروید و برای ادغامهای بزرگ ST_UnaryUnion را ترجیح دهید. برای هندسههای حجیم از ST_Subdivide و در صورت امکان از کاهش جزئیات با ST_SimplifyPreserveTopology یا ST_SnapToGrid بهره ببرید. همچنین: ایندکس GiST بسازید، فیلترهای صفتی را زود اعمال کنید، از اعمال توابع روی ستون هندسی در WHERE که جلوی استفاده از ایندکس را میگیرد پرهیز کنید، و با EXPLAIN صحت استفاده از ایندکس و برآوردها را بررسی کنید. نتیجهٔ عملی: انتخاب predicate مناسب، اجتناب از overlay غیرضروری، و نگهداشتن هندسهها و ایندکسها در وضعیتی سازگار با برنامهریز، کارایی پایدار PostgreSQL/PostGIS را تضمین میکند.
#PostGIS #PostgreSQL #GIS #GEOS #SpatialIndex #ST_Intersects #Geospatial #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/177315/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostGIS Performance: Intersection Predicates and Overlays
🟢 خلاصه مقاله:
خلاصهای از یک نوشته در ادامهٔ مجموعهای برای بهبود کارایی PostGIS است که بر دو بخش کلیدی تمرکز دارد: «intersection predicates» مثل ST_Intersects، ST_Touches و ST_Contains و «overlay»ها مثل ST_Intersection و ST_Union. راهبرد اصلی این است: ابتدا با فیلتر سریع جعبهمحیطی (&& روی ایندکس GiST) تعداد کاندیداها را کم کنید و سپس رابطهٔ دقیق را با GEOS بررسی کنید. برای پرسوجوهای معمول، سادهترین predicate که نیازتان را پوشش میدهد انتخاب شود؛ از ST_Intersects برای joinهای اولیه استفاده و در صورت نیاز دقیقتر کنید. عملیات overlay چون هندسهٔ جدید میسازند، پرهزینهاند؛ فقط وقتی واقعاً خروجی هندسی لازم است سراغشان بروید و برای ادغامهای بزرگ ST_UnaryUnion را ترجیح دهید. برای هندسههای حجیم از ST_Subdivide و در صورت امکان از کاهش جزئیات با ST_SimplifyPreserveTopology یا ST_SnapToGrid بهره ببرید. همچنین: ایندکس GiST بسازید، فیلترهای صفتی را زود اعمال کنید، از اعمال توابع روی ستون هندسی در WHERE که جلوی استفاده از ایندکس را میگیرد پرهیز کنید، و با EXPLAIN صحت استفاده از ایندکس و برآوردها را بررسی کنید. نتیجهٔ عملی: انتخاب predicate مناسب، اجتناب از overlay غیرضروری، و نگهداشتن هندسهها و ایندکسها در وضعیتی سازگار با برنامهریز، کارایی پایدار PostgreSQL/PostGIS را تضمین میکند.
#PostGIS #PostgreSQL #GIS #GEOS #SpatialIndex #ST_Intersects #Geospatial #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/177315/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
PostGIS Performance: Intersection Predicates and Overlays | Crunchy Data Blog
What is difference between the boolean true / false ST_Intersects and ST_Contains and the overlay options of ST_Intersection and ST_Difference? Also, combining these two ideas can get you really fast queries for geometries fully contained inside areas.