👎 PostgreSQL Partitioning’ning Kamchiliklari
Partition zo‘r narsa, lekin har bir "qulaylik" o‘z narxiga ega. Endi uning kamchiliklari haqida gaplashamiz:
❌ 1. Yozish (INSERT) sekinlashuvi
Ko‘pchilik o‘ylaydi: "Partition faqat tezlashtiradi!"
Yo‘q, INSERT operatsiyasi har safar to‘g‘ri partition’ni topish uchun qo‘shimcha tekshiruvlardan o‘tadi.
Ayniqsa, ko‘p bo‘lakli (many partitions) strukturada bu sezilarli kechikishga olib kelishi mumkin.
❌ 2. Trigger va Foreign Key cheklovlari
Partitionlangan jadvalda foreign key ishlamaydi (child jadval bo‘lishi mumkin emas).
Triggerlarni har bir partition uchun alohida qo‘shish kerak bo‘ladi. Ota jadvalda qo‘shilgan triggerlar child'larda ishlamaydi.
❌ 3. Maintenance murakkabligi
Har bir partition bu alohida jadval. Ularni yaratish, o‘chirish, migratsiya qilish – qo‘shimcha bosh og‘riq.
Agar partitionlar avtomatik yaratilmasa, yangilari qo‘lda yoki dastur orqali qo‘shilishi kerak bo‘ladi.
❌ 4. Planning va optimization murakkablashadi
Query planner noto‘g‘ri partition’ni tanlasa – optimal ishlamaydi.
Ba’zida indeks ishlamay qoladi, chunki u faqat bitta partition’da bor.
❌ 5. Yozishda UPDATE muammolari
Agar UPDATE operatsiyasi partition ajratilgan ustunga ta’sir qilsa, PostgreSQL yozuvni bir partition’dan olib, boshqasiga ko‘chiradi (DELETE + INSERT).
Bu esa performanceni keskin tushiradi.
📌 Xulosa:
Partition – kuchli qurol, lekin uni kerakli joyda va to‘g‘ri strategiya bilan ishlatmasang, aks ta’sir qiladi.
EXPLAIN ANALYZE bilan sinab ko‘r, so‘ngra bo‘laklarga bo‘l!
Partition zo‘r narsa, lekin har bir "qulaylik" o‘z narxiga ega. Endi uning kamchiliklari haqida gaplashamiz:
❌ 1. Yozish (INSERT) sekinlashuvi
Ko‘pchilik o‘ylaydi: "Partition faqat tezlashtiradi!"
Yo‘q, INSERT operatsiyasi har safar to‘g‘ri partition’ni topish uchun qo‘shimcha tekshiruvlardan o‘tadi.
Ayniqsa, ko‘p bo‘lakli (many partitions) strukturada bu sezilarli kechikishga olib kelishi mumkin.
❌ 2. Trigger va Foreign Key cheklovlari
Partitionlangan jadvalda foreign key ishlamaydi (child jadval bo‘lishi mumkin emas).
Triggerlarni har bir partition uchun alohida qo‘shish kerak bo‘ladi. Ota jadvalda qo‘shilgan triggerlar child'larda ishlamaydi.
❌ 3. Maintenance murakkabligi
Har bir partition bu alohida jadval. Ularni yaratish, o‘chirish, migratsiya qilish – qo‘shimcha bosh og‘riq.
Agar partitionlar avtomatik yaratilmasa, yangilari qo‘lda yoki dastur orqali qo‘shilishi kerak bo‘ladi.
❌ 4. Planning va optimization murakkablashadi
Query planner noto‘g‘ri partition’ni tanlasa – optimal ishlamaydi.
Ba’zida indeks ishlamay qoladi, chunki u faqat bitta partition’da bor.
❌ 5. Yozishda UPDATE muammolari
Agar UPDATE operatsiyasi partition ajratilgan ustunga ta’sir qilsa, PostgreSQL yozuvni bir partition’dan olib, boshqasiga ko‘chiradi (DELETE + INSERT).
Bu esa performanceni keskin tushiradi.
📌 Xulosa:
Partition – kuchli qurol, lekin uni kerakli joyda va to‘g‘ri strategiya bilan ishlatmasang, aks ta’sir qiladi.
EXPLAIN ANALYZE bilan sinab ko‘r, so‘ngra bo‘laklarga bo‘l!
SELECT (SELECT COUNT(*) FROM users) AS total_users,
(SELECT COUNT(*)
FROM users u
INNER JOIN user_data ud ON ud.user_id = u.id) AS total_registered,
(SELECT COUNT(*) FROM events) AS total_events,
(SELECT COUNT(*) FROM send_message) AS total_send_messages;
👍1👀1
SELECT ue.id,
ue."rsvpChoice" AS rsvp_choice,
ue."isRspv" AS is_rspv,
ue."isAttendance" AS is_attendance,
jsonb_build_object('id', u.id, 'tgId', u.tg_id, 'uniqueCode', u.user_unique_code) as user,
jsonb_build_object('id', ud.id, 'name', ud.name, 'surname', ud.surname) AS user_data
FROM user_events ue
LEFT JOIN users u ON ue.user_id = u.id
LEFT JOIN user_data ud ON ud.user_id = u.id
WHERE ue.event_id = 87;
👍1👀1
SELECT e.id,
e.name,
e.date,
e.location,
e.description,
e.category,
SUM(CASE WHEN ue."isRspv" = TRUE THEN 1 ELSE 0 END) AS total_rsvp,
SUM(CASE WHEN ue."isAttendance" = TRUE THEN 1 ELSE 0 END) AS total_attendance
FROM events e
LEFT JOIN user_events ue ON ue.event_id = e.id
WHERE e.id = 87
GROUP BY e.id,
e.name,
e.date,
e.location,
e.description,
e.category
ORDER BY e.date DESC
LIMIT 20 OFFSET 0;
👀1
SELECT
chu.telegram_id as channel_user_tg_id,
u.tg_id as user_tg_id,
ub.id AS user_bot_id,
EXISTS (
SELECT 1
FROM user_bot_plans ubp
WHERE ubp.user_bot_id = ub.id
AND ubp.retry_date::date >= CURRENT_DATE - INTERVAL '1 day'
) AS has_plan
FROM channel_users chu
LEFT JOIN users u
ON chu.telegram_id = u.tg_id
LEFT JOIN user_bots ub
ON ub.user_id = u.id
WHERE ub.bot_id = chu.bot_id
AND chu.created_at::date = CURRENT_DATE - INTERVAL '1 day'
AND chu.bot_id = 18 AND ub.bot_id = 18;
EXACT MATCH
🔥1👏1