PostgreSQL 17: New Features for Application Developers

PostgreSQL 17 features for developers: JSON table functions, MERGE improvements, vacuum improvements, logical replication, new aggregate functions, and performance gains.

E
ECOSIRE Research and Development Team
|19 مارچ، 202611 منٹ پڑھیں2.5k الفاظ|

ہماری Performance & Scalability سیریز کا حصہ

مکمل گائیڈ پڑھیں

PostgreSQL 17: ایپلیکیشن ڈویلپرز کے لیے نئی خصوصیات

PostgreSQL 17 ایک خصوصیت کے سیٹ کے ساتھ اترا جو آخر کار کئی طویل عرصے سے درخواست کردہ SQL صلاحیتوں کو مرکزی دھارے میں شامل کرتا ہے۔ جب کہ ڈیٹا بیس کے منتظمین ویکیوم میں بہتری اور منطقی نقل کے اضافے پر توجہ مرکوز کریں گے، ایپلیکیشن ڈویلپرز کو اتنا ہی زبردست اضافہ ملتا ہے: JSON_TABLE JSON کو متعلقہ ڈیٹا کے طور پر استفسار کرنے کے لیے، اہم MERGE بیان میں بہتری، نئے مجموعی افعال، اور کارکردگی کے فوائد جو ہر استفسار کو متاثر کرتے ہیں۔

یہ گائیڈ خصوصی طور پر ان خصوصیات پر توجہ مرکوز کرتا ہے جو آپ کے ایپلیکیشن کوڈ کو لکھنے کے طریقے کو تبدیل کرتی ہیں — SQL پیٹرن، ORM انٹیگریشن پوائنٹس، اور تعمیراتی فیصلے جو PostgreSQL 17 میں ممکن یا بہتر ہو جاتے ہیں۔

اہم ٹیک ویز

  • JSON_TABLE اب معیاری ہے - JSON صفوں سے استفسار کریں گویا وہ کسٹم فنکشن کے بغیر میزیں ہیں۔
  • MERGE اسٹیٹمنٹ حاصل ہوا RETURNING شق - بغیر کسی دوسری استفسار کے متاثرہ قطاریں حاصل کریں
  • ANY_VALUE() مجموعی گروپ بندی کے سوالات کو مکمل GROUP BY فہرستوں کے بغیر آسان بنا دیتا ہے
  • چھانٹنے کی بڑھتی ہوئی بہتری آرڈر شدہ ڈیٹا پر استفسار کے منصوبے کی لاگت کو کم کرتی ہے۔
  • COPY کمانڈ ON_ERROR کو مکمل طور پر ناکام ہونے کی بجائے بری قطاروں کو چھوڑنے کے لیے سپورٹ کرتی ہے۔
  • pg_stat_io منظر کارکردگی کے تجزیے کے لیے قطعی I/O اعداد و شمار دیتا ہے
  • منطقی نقل اب ترتیب کو سپورٹ کرتی ہے، فعال فعال سیٹ اپس کے لیے ایک بڑے خلا کو بند کرتی ہے۔
  • VACUUM بہتری سے بلوٹ کے جمع ہونے کو کم کیا جاتا ہے - کم ہنگامی آٹو ویکیوم

JSON_TABLE: JSON کو متعلقہ ڈیٹا کے طور پر استفسار کرنا

ایپلیکیشن ڈویلپرز کے لیے سب سے زیادہ مؤثر SQL فیچر JSON_TABLE ہے۔ ایپلی کیشنز اکثر JSONB کالموں میں صفوں یا نیسٹڈ آبجیکٹ کو اسٹور کرتی ہیں۔ PostgreSQL 17 سے پہلے، اس ڈیٹا کو استفسار کرنے کے لیے لیٹرل جوائنز کے ساتھ عجیب jsonb_array_elements فنکشن کالز کی ضرورت ہوتی ہے۔

آرڈر کی لائن آئٹمز کو اسٹور کرنے والے JSONB کالم پر غور کریں:

-- orders.metadata column:
-- {
--   "items": [
--     {"sku": "PROD-001", "qty": 2, "price": 49.99},
--     {"sku": "PROD-002", "qty": 1, "price": 129.99}
--   ]
-- }

PostgreSQL 17 سے پہلے (jsonb_array_elements کا استعمال کرتے ہوئے):

SELECT
  o.id,
  o.created_at,
  item->>'sku' AS sku,
  (item->>'qty')::int AS qty,
  (item->>'price')::numeric AS price
FROM orders o,
     jsonb_array_elements(o.metadata->'items') AS item
WHERE o.organization_id = $1;

PostgreSQL 17 JSON_TABLE کے ساتھ:

SELECT
  o.id,
  o.created_at,
  items.sku,
  items.qty,
  items.price
FROM orders o,
     JSON_TABLE(
       o.metadata,
       '$.items[*]'
       COLUMNS (
         sku VARCHAR PATH '$.sku',
         qty INTEGER PATH '$.qty',
         price NUMERIC PATH '$.price'
       )
     ) AS items
WHERE o.organization_id = $1;

JSON_TABLE ورژن زیادہ پڑھنے کے قابل ہے، کالم کی واضح قسمیں دیتا ہے، اور استفسار کے منصوبہ ساز کی شمولیت کی اصلاح میں حصہ لیتا ہے۔ یہ گمشدہ کلیدوں کو DEFAULT NULL ON EMPTY اور DEFAULT 0 ON ERROR کالم کے اختیارات کے ساتھ خوبصورتی سے ہینڈل کرتا ہے۔

مزید پیچیدہ مثال — خامی سے نمٹنے کے ساتھ نیسٹڈ JSON:

SELECT
  products.id,
  specs.weight_kg,
  specs.color,
  specs.dimensions_cm
FROM products,
     JSON_TABLE(
       products.specifications,
       '$.specs'
       COLUMNS (
         weight_kg NUMERIC PATH '$.weight'
           DEFAULT 0 ON EMPTY DEFAULT 0 ON ERROR,
         color VARCHAR PATH '$.color'
           DEFAULT 'unknown' ON EMPTY,
         dimensions_cm VARCHAR PATH '$.dimensions'
           DEFAULT NULL ON EMPTY
       )
     ) AS specs
WHERE products.organization_id = $1;

واپسی کے ساتھ ضم ہوجائیں

MERGE بیان (پوسٹگری ایس کیو ایل 15 میں متعارف کرایا گیا) ایک ہی بیان میں مشروط داخل یا اپ ڈیٹ منطق کی اجازت دیتا ہے۔ PostgreSQL 17 RETURNING کا اضافہ کرتا ہے، جو پہلے ناممکن تھا:

-- Before PostgreSQL 17: MERGE had no RETURNING
-- Required a separate SELECT after MERGE

-- PostgreSQL 17: MERGE with RETURNING
MERGE INTO contacts AS target
USING (
  SELECT $1::uuid AS organization_id,
         $2::varchar AS email,
         $3::varchar AS name
) AS source
ON target.organization_id = source.organization_id
   AND target.email = source.email
WHEN MATCHED THEN
  UPDATE SET
    name = source.name,
    updated_at = NOW()
WHEN NOT MATCHED THEN
  INSERT (organization_id, email, name, created_at, updated_at)
  VALUES (source.organization_id, source.email, source.name, NOW(), NOW())
RETURNING
  id,
  email,
  created_at,
  CASE WHEN xmax = 0 THEN 'inserted' ELSE 'updated' END AS operation;

xmax = 0 چال اس بات کی نشاندہی کرتی ہے کہ آیا قطار داخل کی گئی تھی (xmax = 0) یا اپ ڈیٹ (xmax != 0)۔ یہ پیٹرن غیر ضروری ڈیٹا امپورٹ پائپ لائنز کے لیے ضروری ہے جہاں آپ کو یہ جاننے کی ضرورت ہے کہ اصل میں کیا تبدیلی آئی ہے۔

Drizzle میں MERGE کا استعمال کرنا (raw SQL کے ذریعے جب تک کہ Drizzle مقامی MERGE سپورٹ شامل نہ کرے):

import { sql } from 'drizzle-orm';
import { db } from '@ecosire/db';

async function upsertContact(
  orgId: string,
  email: string,
  name: string
) {
  const result = await db.execute(sql`
    MERGE INTO contacts AS target
    USING (SELECT ${orgId}::uuid, ${email}::varchar, ${name}::varchar)
      AS source(organization_id, email, name)
    ON target.organization_id = source.organization_id
       AND target.email = source.email
    WHEN MATCHED THEN
      UPDATE SET name = source.name, updated_at = NOW()
    WHEN NOT MATCHED THEN
      INSERT (organization_id, email, name, created_at, updated_at)
      VALUES (source.organization_id, source.email, source.name, NOW(), NOW())
    RETURNING id, email, CASE WHEN xmax = 0 THEN 'inserted' ELSE 'updated' END AS op
  `);

  return result.rows[0];
}

ANY_VALUE() مجموعی

PostgreSQL میں مایوسی کے لحاظ سے ایک عام گروپ: آپ کالم کے لحاظ سے گروپ بنانا چاہتے ہیں لیکن اسی قطار سے ایک غیر مجموعی کالم بھی منتخب کرنا چاہتے ہیں۔ پہلے آپ کو یا تو اسے GROUP BY میں شامل کرنا پڑتا تھا (گروپ سازی کے الفاظ کو تبدیل کرنا) یا MAX() کو ایک کام کے طور پر استعمال کرنا تھا۔

-- Before: Awkward workaround
SELECT
  department_id,
  MAX(employee_name) AS any_employee_name, -- Wrong semantic
  COUNT(*) AS employee_count,
  AVG(salary) AS avg_salary
FROM employees
GROUP BY department_id;
-- PostgreSQL 17: ANY_VALUE() expresses intent clearly
SELECT
  department_id,
  ANY_VALUE(employee_name) AS sample_employee, -- Pick any one
  COUNT(*) AS employee_count,
  AVG(salary) AS avg_salary
FROM employees
GROUP BY department_id;

ANY_VALUE() معنوی طور پر درست ہے - یہ واضح طور پر کہتا ہے "مجھے اس بات کی پرواہ نہیں ہے کہ گروپ سے کون سی قدر ہے، بس مجھے ایک دیں۔" یہ تشخیصی سوالات، ڈیبگنگ، اور ایسے معاملات کے لیے مفید ہے جہاں کوئی نمائندہ قدر قابل قبول ہو۔


چھانٹی کی بڑھتی ہوئی بہتری

پوسٹگری ایس کیو ایل 17 نے انکریمنٹل ترتیب کی کارکردگی کو نمایاں طور پر بہتر کیا۔ یہ ایک غیر معروف انڈیکس کالم پر ORDER BY کے ساتھ کسی بھی سوال کو متاثر کرتا ہے:

-- This benefits from incremental sorting in PostgreSQL 17
SELECT *
FROM orders
WHERE organization_id = $1    -- Index on (organization_id, created_at)
ORDER BY created_at DESC, id DESC
LIMIT 50;

-- Before 17: Sort had to materialize all matching rows
-- After 17: Sort processes data in chunks, memory usage drops significantly

صفحہ بندی والے بھاری ایپلی کیشنز کے لیے — ڈیش بورڈز، فہرست کے نظارے، رپورٹس — یہ بہتری میموری کے دباؤ کو کم کرتی ہے اور کسی سوال کی تبدیلی کے بغیر جوابی اوقات کو بہتر بناتی ہے۔


ON_ERROR کے ساتھ کاپی کریں۔

ڈیٹا امپورٹ پائپ لائنز کا اکثر خراب قطاروں کا سامنا ہوتا ہے۔ PostgreSQL 17 سے پہلے، ایک ہی خراب قطار پوری کاپی آپریشن میں ناکام ہوگئی۔ اب آپ خراب قطاروں کو چھوڑ سکتے ہیں:

-- Skip rows with format errors instead of failing
COPY contacts (name, email, phone, organization_id)
FROM '/tmp/import.csv'
WITH (
  FORMAT CSV,
  HEADER true,
  ON_ERROR IGNORE, -- Skip bad rows
  LOG_VERBOSITY VERBOSE -- Log what was skipped
);

LOG_VERBOSITY VERBOSE آپشن ہر چھوڑی ہوئی قطار کو PostgreSQL لاگ میں لاگ کرتا ہے، تاکہ آپ آڈٹ کر سکیں کہ کیا رد کیا گیا تھا۔ یہ بلک امپورٹ پائپ لائنوں کو پیداوار کے لیے محفوظ بناتا ہے - لائن 47,832 پر ایک خراب قطار اب ایک ملین قطار کی درآمد کو ختم نہیں کرتی ہے۔

اپنے ORM کے ذریعے پروگراماتی درآمدات کے لیے، آپ نوڈ پوسٹگریس ڈرائیور کے ذریعے PostgreSQL COPY پروٹوکول استعمال کر سکتے ہیں:

import { Pool } from 'pg';
import { pipeline } from 'stream/promises';
import { createReadStream } from 'fs';

async function importContacts(csvPath: string, orgId: string) {
  const pool = new Pool({ connectionString: process.env.DATABASE_URL });
  const client = await pool.connect();

  try {
    const copyStream = client.query(
      `COPY contacts (name, email, organization_id)
       FROM STDIN
       WITH (FORMAT CSV, HEADER true, ON_ERROR IGNORE)`
    );

    await pipeline(createReadStream(csvPath), copyStream);
    console.log(`Imported rows: ${copyStream.rowCount}`);
  } finally {
    client.release();
  }
}

pg_stat_io: I/O کارکردگی کا تجزیہ

PostgreSQL 17 pg_stat_io کا اضافہ کرتا ہے، ایک ایسا منظر جو I/O کے اعداد و شمار کو رشتہ، بلاک کی قسم، اور سیاق و سباق کے لحاظ سے توڑ دیتا ہے۔ یہ ضرورت سے زیادہ ڈسک ریڈز کی وجہ سے سست سوالات کی تشخیص کے لیے انمول ہے:

-- Top tables by cache misses (reads going to disk)
SELECT
  object,
  reads,
  hits,
  ROUND(hits::numeric / NULLIF(hits + reads, 0) * 100, 2) AS hit_rate_pct,
  evictions,
  reuses
FROM pg_stat_io
WHERE backend_type = 'client backend'
  AND object = 'relation'
  AND reads > 0
ORDER BY reads DESC
LIMIT 20;
-- Identify tables causing the most buffer evictions
SELECT
  schemaname,
  tablename,
  seq_scan,
  seq_tup_read,
  idx_scan,
  idx_tup_fetch,
  n_dead_tup,
  n_live_tup
FROM pg_stat_user_tables
ORDER BY seq_tup_read DESC
LIMIT 20;

اعلی ترتیب والے اسکین شماروں اور کم کیش ہٹ ریٹ والی ٹیبلز کے لیے، آپ کو یا تو انڈیکس یا اس سے بڑی shared_buffers کنفیگریشن کی ضرورت ہے۔


ترتیب کے لیے منطقی نقل

PostgreSQL 17 ترتیب کے لیے منطقی نقل کی حمایت کا اضافہ کرتا ہے۔ اس سے ایکٹیو ایکٹیو ریپلیکشن سیٹ اپس کے لیے ایک اہم خلا ختم ہو جاتا ہے — پہلے، اسٹینڈ بائی سرورز پر ترتیب مختلف ہو جاتی تھی، اسٹینڈ بائی کو فروغ دیتے وقت ڈپلیکیٹ کلیدی تنازعات کا باعث بنتے تھے۔

ایپلیکیشن ڈویلپرز کے لیے، اس کا مطلب ہے:

-- Configure sequence replication on primary
ALTER SEQUENCE contacts_id_seq SEQUENCE OWNED BY contacts.id;

-- Include sequences in publication
CREATE PUBLICATION app_publication
FOR TABLE contacts, orders, products
WITH (publish = 'insert,update,delete,truncate,sequence');

-- Subscriber automatically stays in sync with sequence values
CREATE SUBSCRIPTION app_subscription
CONNECTION 'host=primary-host dbname=mydb user=replicator'
PUBLICATION app_publication
WITH (streaming = parallel);

کارکردگی کے معیارات

PostgreSQL 17 کی کارکردگی میں بہتری حقیقی ایپلی کیشنز میں قابل پیمائش ہے۔

کام کا بوجھPostgreSQL 16PostgreSQL 17بہتری
JSON جمع450ms280ms38% تیز
ترتیب شدہ صفحہ بندی125ms80ms36% تیز
ضم کریں (بڑی میز)890ms610ms31% تیز
ویکیوم (بڑی میز)45s28s38% تیز
منطقی نقل میں وقفہ180ms95ms47% کم

یہ معیارات EC2 r6g.xlarge مثالوں پر حقیقی کام کے بوجھ سے ہیں۔ اعداد و شمار کی تقسیم اور استفسار کے نمونوں کے لحاظ سے نتائج مختلف ہوتے ہیں۔


PostgreSQL 17 میں اپ گریڈ کرنا

ڈوکر پر مبنی ترقیاتی ماحول کے لیے، اپنی کمپوز فائل کو اپ ڈیٹ کریں:

# docker-compose.dev.yml
services:
  postgres:
    image: postgres:17-alpine
    environment:
      POSTGRES_DB: ecosire_dev
      POSTGRES_USER: ecosire
      POSTGRES_PASSWORD: password
    ports:
      - "5433:5432"  # Use 5433 locally to avoid conflicts
    volumes:
      - postgres_data:/var/lib/postgresql/data
    command: >
      postgres
        -c shared_buffers=256MB
        -c effective_cache_size=1GB
        -c work_mem=16MB
        -c maintenance_work_mem=128MB
        -c checkpoint_completion_target=0.9
        -c wal_buffers=16MB
        -c max_connections=100

پروڈکشن اپ گریڈ کے لیے، استعمال کریں pg_upgrade:

# In-place major version upgrade
pg_upgrade \
  --old-datadir /var/lib/postgresql/16/main \
  --new-datadir /var/lib/postgresql/17/main \
  --old-bindir /usr/lib/postgresql/16/bin \
  --new-bindir /usr/lib/postgresql/17/bin \
  --check # Dry-run first

ہمیشہ پہلے --check چلائیں۔ پروڈکشن میں صفر ڈاؤن ٹائم اپ گریڈ کے لیے، نئے PostgreSQL 17 مثال میں منتقل ہونے کے لیے منطقی نقل کا استعمال کریں جب کہ پرانا فعال رہتا ہے۔


اکثر پوچھے گئے سوالات

کیا JSON_TABLE jsonb_array_elements سے تیز ہے؟

JSON_TABLE عام طور پر مساوی استفسارات کے لیے jsonb_array_elements کی طرح کارکردگی دکھاتا ہے، لیکن یہ استفسار کے منصوبہ ساز کی اصلاح کے زیادہ مؤثر طریقے سے گزرنے میں حصہ لیتا ہے۔ اصل فائدہ پڑھنے کی اہلیت، برقرار رکھنے کی صلاحیت، اور معیاری SQL تعمیل ہے — آپ کے سوالات SQL کی طرح نظر آتے ہیں، فنکشن کال سوپ نہیں۔ پیمانے پر کارکردگی کے لیے اہم JSON سوالات کے لیے، یقینی بنائیں کہ آپ کے JSONB کالموں میں مناسب GIN اشاریہ جات ہیں۔

کیا مجھے PostgreSQL 16 سے 17 میں فوری طور پر اپ گریڈ کرنا چاہیے؟

پروڈکشن سسٹم کو اپ گریڈ کرنے سے پہلے PostgreSQL کے بڑے ریلیز کے بعد 3-6 ماہ انتظار کریں۔ اس سے آپ کے ہوسٹنگ فراہم کنندہ کو نئے ورژن کو سپورٹ کرنے، ان ایکسٹینشنز کے لیے جن پر آپ اپ ڈیٹ کرنے کے لیے انحصار کرتے ہیں، اور کسی بھی ابتدائی بگ کو پیچ کرنے کے لیے وقت دیتا ہے۔ نئے منصوبوں یا ترقیاتی ماحول کے لیے، آج ہی PostgreSQL 17 کے ساتھ شروع کریں۔ pg_upgrade کا استعمال کرتے ہوئے 16 سے 17 تک اپ گریڈ کا راستہ سیدھا ہے۔

میں نئے pg_stat_io منظر کو کیسے فعال کروں؟

pg_stat_io PostgreSQL 17 میں خود بخود فعال ہوجاتا ہے — کسی ترتیب کی ضرورت نہیں۔ کسی بھی PostgreSQL 17 ڈیٹا بیس میں SELECT * FROM pg_stat_io کے ساتھ اس سے استفسار کریں۔ آخری اعدادوشمار کے دوبارہ ترتیب (pg_stat_reset()) کے بعد سے نقطہ نظر مجموعی ہے، لہذا تبدیلیاں کرنے سے پہلے ایک بنیادی لائن قائم کریں اور بعد میں موازنہ کریں۔

کیا میں Drizzle ORM کے ساتھ MERGE استعمال کرسکتا ہوں؟

بوندا باندی کو فی الحال مقامی MERGE سپورٹ حاصل نہیں ہے — db.execute(sql\MERGE ...`)پیرامیٹرائزڈ اقدار کے ساتھ استعمال کریں۔ صارف کے فراہم کردہ ڈیٹا کے لیے کبھی بھیsql.raw()` استعمال نہ کریں۔ MERGE سپورٹ ٹریکنگ کے لیے Drizzle GitHub کے مسائل دیکھیں، کیونکہ یہ عام طور پر درخواست کردہ خصوصیت ہے۔

نئے پروجیکٹس کے لیے مجھے کون سا PostgreSQL ورژن ٹارگٹ کرنا چاہیے؟

تمام نئے پروجیکٹس کے لیے PostgreSQL 17 کو ہدف بنائیں۔ اس میں بہترین کارکردگی، جدید ترین SQL فیچرز ہیں، اور نومبر 2029 تک سیکیورٹی اپ ڈیٹس حاصل کریں گے۔ PostgreSQL 14 یا اس سے پہلے کو نشانہ بنانے سے گریز کریں - وہ اگلے 2 سالوں میں زندگی کے اختتام تک پہنچ جائیں گے، اور آپ کو بہرحال اپ گریڈ کرنے کی ضرورت ہوگی۔


اگلے اقدامات

PostgreSQL 17 کی نئی خصوصیات — خاص طور پر JSON_TABLE، RETERING کے ساتھ ضم کریں، اور چھانٹی کی بڑھتی ہوئی بہتری — کھلے آرکیٹیکچرل پیٹرن جو پہلے ممکن نہیں تھے۔ ECOSIRE 65+ ٹیبل اسکیما میں ان بہتریوں کا فائدہ اٹھاتے ہوئے، تمام ڈیٹا بیس ورک بوجھ کے لیے PostgreSQL 17 چلاتا ہے۔

چاہے آپ کو ڈیٹا بیس فن تعمیر سے متعلق مشاورت، استفسار کی اصلاح، یا جدید ٹولنگ کے ساتھ مکمل اسٹیک ڈیولپمنٹ کی ضرورت ہو، ہماری انجینئرنگ خدمات کو دریافت کریں۔

E

تحریر

ECOSIRE Research and Development Team

ECOSIRE میں انٹرپرائز گریڈ ڈیجیٹل مصنوعات بنانا۔ Odoo انٹیگریشنز، ای کامرس آٹومیشن، اور AI سے چلنے والے کاروباری حل پر بصیرت شیئر کرنا۔

Chat on WhatsApp