SELECT setval('track_codes_id_seq', 11062);
shu yerda turib tursin. Birozdan keyiin tushuntirib yozvoraman!
shu yerda turib tursin. Birozdan keyiin tushuntirib yozvoraman!
SELECT setval('track_codes_id_seq', 11062); so'rovi track_codes_id_seq deb nomlangan SEQUENCE ning hozirgi qiymatini 11062 ga sozlaydi. Keling, qadamlar bo'yicha tushuntirib o'taman:### 1. SEQUENCE nima?
PostgreSQL-da
SERIAL yoki BIGSERIAL tipidagi ustunlar avtomatik ravishda ketma-ket tartibda raqamlanadi. Buning uchun PostgreSQL har bir ustun uchun "SEQUENCE" yaratadi. Bu SEQUENCE keyingi yozuvlar uchun id yoki boshqa avtomatik qiymatlarni o'z ichiga oladi va tartiblab beradi.Misol uchun, agar sizda
id ustuni SERIAL deb belgilangan bo'lsa, har bir yangi yozuv qo'shilganda, bu ustunga avvalgi qiymatdan bir birlikka katta raqam avtomatik beriladi.### 2. `setval` funksiyasi nima qiladi?
setval funksiyasi siz ko'rsatgan SEQUENCE qiymatini majburan o'zgartiradi va uni qo'yilgan qiymatga to'g'rilaydi. Bu funksiya sizga SEQUENCE ni qo'lda boshqarish imkonini beradi.### 3. So'rovning maqsadi
Bu so'rov
track_codes_id_seq deb nomlangan SEQUENCE ning keyingi qiymatini 11062 qilib o'rnatadi. Bu shuni anglatadi:- Agar keyingi yozuv
track_codes jadvaliga qo'shilsa, uning id qiymati avtomatik ravishda 11063 bo'ladi (chunki setval 11062 ga o'rnatilgan).### Qachon ishlatiladi?
- Agar siz jadvalga qo'lda ma'lumot kiritgan bo'lsangiz va
SEQUENCE bilan ishlaydigan avtomatik qiymat izdan chiqqan bo'lsa (masalan, id ustuni allaqachon qo'lda yuqori raqamli qiymatlar olgan bo'lsa), siz SEQUENCE qiymatini bu usulda tiklashingiz kerak bo'ladi.- Yoki eski yozuvlarni o'chirib tashlab, keyingi
id qiymatini yangi raqamdan boshlashni istasangiz.### Misol:
Agar
track_codes jadvalida hozirgi eng katta id qiymati 11062 bo'lsa va siz SEQUENCE ni to'g'rilamasangiz, keyingi yozuv uchun id qiymati kichikroq yoki noto'g'ri bo'lishi mumkin. setval yordamida siz keyingi yozuvni to'g'ri tartibda davom ettirish uchun SEQUENCE ni 11062 ga to'g'irlaysiz, shunda keyingi yozuv 11063 raqamidan boshlanadi.### Yakuniy natija:
-
setval('track_codes_id_seq', 11062); keyingi yozuv uchun id qiymatini 11063 qilib sozlash uchun SEQUENCE ni 11062 ga o'rnatadi.👍2
EXPLAIN ANALYZE SELECT * FROM Users WHERE user_id = 5300157486;
Bazada so'rov ning qanchalik tez ishlayotganini ko'rsatuvchi sql query hisoblanadi. Juda kerakli query ayniqsa dasturingiz sekin ishlayotgan vaqt va siz uni tezlashtirmoqchi bo'lganingizda.
@psql_tutorial
🔥2👍1
SELECT query, calls, total_time, mean_time
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;
Bu query bazada eng kop vaqt olayotgan so'rovlarni topish uchun ishlatasiz.
Agar statistika pg_stat_statements yoqilmagan bo'lsa quyidagi so'rov bilan yoqasiz: 👇
CREATE EXTENSION pg_stat_statements;
Kopchilik cloud psql bazalarda bu extension uchun dostup yoq ammo support bilan "otnosheniya" qilib yoqtirib olsangiz bo'ladi 😅 😉
menda hozir pg_stat_statements extension uchun dostup yo'q ekan TIMEWEB CLOUD PSQL bazasida endi adminkalar bilan "otnosheniya" qilib yoqtirib olishim kerak 😅
❤1🆒1
Juda katta hajmdagi malumotlarni bazaga kiritish bo'yicha eng yaxshi usullar:
BULK INSERT👇
ENG TEZ USUL (COPY FROM) 🚀
BULK INSERT👇
INSERT INTO users (name, email)
VALUES
('User1', 'user1@example.com'),
('User2', 'user2@example.com'),
...
('User1000', 'user1000@example.com');
ENG TEZ USUL (COPY FROM) 🚀
COPY users(name, email) FROM '/path/to/data.csv' DELIMITER ',' CSV HEADER;
👍5
SELECT
(
SELECT COUNT(*)
FROM user_bots ub2
WHERE ub2.bot_id = ub.bot_id
AND ub2.in_channel = TRUE
AND DATE(ub2.created_at) BETWEEN $2 AND $3
) AS subscribers_in_channel,
(
SELECT COALESCE(ROUND(SUM(tm.price) / 100.0, 0), 0)
FROM transaction_meta tm
WHERE tm.bot_id = ub.bot_id
AND tm.status = 'success'
AND DATE(tm.created_at) BETWEEN $2 AND $3
) AS total_revenue_today,
(
SELECT COUNT(*)
FROM transaction_meta tm
WHERE tm.bot_id = ub.bot_id
AND tm.status = 'success'
AND DATE(tm.created_at) BETWEEN $2 AND $3
) AS sales_today,
(
SELECT COALESCE(ROUND(AVG(tm.price) / 100.0, 0), 0)
FROM transaction_meta tm
WHERE tm.bot_id = ub.bot_id
AND tm.status = 'success'
AND DATE(tm.created_at) BETWEEN $2 AND $3
) AS average_sale_price_today
FROM user_bots ub
WHERE ub.bot_id = $1
GROUP BY ub.bot_id;
🤝2❤1
📌 PostgreSQL’da Partition nima va nega u muhim?
#PostgreSQL #Partition #DatabaseOptimization
🔹 Partitioning — bu katta hajmdagi jadvalni bo‘laklarga ajratish texnikasi. Bu bo‘laklar partition deb ataladi va ular asosan samaradorlikni oshirish va qidiruvni tezlashtirish uchun ishlatiladi.
💡 Tasavvur qil:
Senda 100 million qatorli orders jadvali bor. Har safar qidiruv qilishda butun jadvalni ko‘zdan kechirish kerakmi? Yo‘q, buning o‘rniga orders_2023, orders_2024, orders_2025 kabi yil bo‘yicha bo‘lingan partition’lar foydali bo‘ladi.
⸻
🔧 Partition turlari:
1. Range Partitioning – ma’lumotlar qiymat oralig‘iga qarab ajratiladi.
Misol: date BETWEEN '2024-01-01' AND '2024-12-31'
2. List Partitioning – muayyan qiymatlarga qarab bo‘linadi.
Misol: region IN ('Toshkent', 'Fargʻona')
3. Hash Partitioning – ma’lumotlar hash funksiyasi orqali bo‘linadi.
Misol: user_id % 4
⸻
✅ Afzalliklari:
• Performance oshadi – kerakli partition’ni skanerlash kifoya.
• Ma’lumotni boshqarish osonlashadi – eski partlarni arxivlash, o‘chirish, yoki zaxiralash mumkin.
• Parallel query’lar – bir nechta partition ustida bir vaqtning o‘zida ishlaydi.
📚 P.S.: Partition ishlatish — bu katta hajmdagi jadval bilan ishlayotgan professional backendchilar uchun “must-know” texnika. Ayniqsa, vaqt bo‘yicha statistika, arxiv, loglar va billing tizimlarida juda asqotadi.
#PostgreSQL #Partition #DatabaseOptimization
🔹 Partitioning — bu katta hajmdagi jadvalni bo‘laklarga ajratish texnikasi. Bu bo‘laklar partition deb ataladi va ular asosan samaradorlikni oshirish va qidiruvni tezlashtirish uchun ishlatiladi.
💡 Tasavvur qil:
Senda 100 million qatorli orders jadvali bor. Har safar qidiruv qilishda butun jadvalni ko‘zdan kechirish kerakmi? Yo‘q, buning o‘rniga orders_2023, orders_2024, orders_2025 kabi yil bo‘yicha bo‘lingan partition’lar foydali bo‘ladi.
⸻
🔧 Partition turlari:
1. Range Partitioning – ma’lumotlar qiymat oralig‘iga qarab ajratiladi.
Misol: date BETWEEN '2024-01-01' AND '2024-12-31'
2. List Partitioning – muayyan qiymatlarga qarab bo‘linadi.
Misol: region IN ('Toshkent', 'Fargʻona')
3. Hash Partitioning – ma’lumotlar hash funksiyasi orqali bo‘linadi.
Misol: user_id % 4
⸻
✅ Afzalliklari:
• Performance oshadi – kerakli partition’ni skanerlash kifoya.
• Ma’lumotni boshqarish osonlashadi – eski partlarni arxivlash, o‘chirish, yoki zaxiralash mumkin.
• Parallel query’lar – bir nechta partition ustida bir vaqtning o‘zida ishlaydi.
CREATE TABLE orders (
id serial,
customer_id int,
order_date date
) PARTITION BY RANGE (order_date);
CREATE TABLE orders_2024 PARTITION OF orders
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
📚 P.S.: Partition ishlatish — bu katta hajmdagi jadval bilan ishlayotgan professional backendchilar uchun “must-know” texnika. Ayniqsa, vaqt bo‘yicha statistika, arxiv, loglar va billing tizimlarida juda asqotadi.
👍3
👎 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!