🔵 عنوان مقاله
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.