คำถามติดแท็ก postgresql-performance

ปัญหาด้านประสิทธิภาพของแบบสอบถาม PostgreSQL

4
วัดขนาดของแถวตาราง PostgreSQL
ฉันมีตาราง PostgreSQL select *ช้ามากในขณะที่select idดีและรวดเร็ว ฉันคิดว่าอาจเป็นไปได้ว่าขนาดของแถวนั้นใหญ่มากและใช้เวลาในการขนส่งสักครู่หรืออาจเป็นปัจจัยอื่น ฉันต้องการฟิลด์ทั้งหมด (หรือเกือบทั้งหมด) ดังนั้นการเลือกเฉพาะเซ็ตย่อยไม่ใช่การแก้ไขด่วน การเลือกเขตข้อมูลที่ฉันต้องการยังคงช้า นี่คือคีคีโต๊ะของฉันลบชื่อ: integer | not null default nextval('core_page_id_seq'::regclass) character varying(255) | not null character varying(64) | not null text | default '{}'::text character varying(255) | integer | not null default 0 text | default '{}'::text text | timestamp with time zone …

6
ฉันจะรับ "แถวที่สอดคล้องกันล่าสุด" อย่างมีประสิทธิภาพได้อย่างไร
ฉันมีรูปแบบแบบสอบถามที่ต้องพบบ่อยมาก แต่ฉันไม่รู้วิธีเขียนแบบสอบถามที่มีประสิทธิภาพ ฉันต้องการค้นหาแถวของตารางที่ตรงกับ "วันที่ล่าสุดไม่หลัง" แถวของตารางอื่น ฉันมีตารางinventoryพูดซึ่งแสดงถึงสินค้าคงคลังที่ฉันถือในวันหนึ่ง date | good | quantity ------------------------------ 2013-08-09 | egg | 5 2013-08-09 | pear | 7 2013-08-02 | egg | 1 2013-08-02 | pear | 2 และโต๊ะ "ราคา" พูดซึ่งถือราคาสินค้าในวันที่กำหนด date | good | price -------------------------- 2013-08-07 | egg | 120 2013-08-06 | pear | …

2
มีการใช้คำสั่งในลำดับที่เขียนหรือไม่
ฉันพยายามเพิ่มประสิทธิภาพการสืบค้นซึ่งมีลักษณะเป็นตารางขนาดใหญ่ (37 ล้านแถว) และมีคำถามเกี่ยวกับลำดับการดำเนินการในแบบสอบถาม select 1 from workdays day where day.date_day >= '2014-10-01' and day.date_day <= '2015-09-30' and day.offer_id in ( select offer.offer_day from offer inner join province on offer.id_province = province.id_province inner join center cr on cr.id_cr = province.id_cr where upper(offer.code_status) <> 'A' and province.id_region in ('10' ,'15' ,'21' …

2
ปรับแต่งแบบสอบถาม Postgres ด้วย IN ขนาดใหญ่
ข้อความค้นหานี้รับรายการโพสต์ที่สร้างโดยคนที่คุณติดตาม คุณสามารถติดตามคนได้ไม่ จำกัด จำนวน แต่คนส่วนใหญ่ติดตามน้อยกว่า 1,000 คน ด้วยการสืบค้นแบบนี้การเพิ่มประสิทธิภาพที่เห็นได้ชัดคือการแคช"Post"รหัส แต่น่าเสียดายที่ฉันไม่มีเวลาสำหรับตอนนี้ EXPLAIN ANALYZE SELECT "Post"."id", "Post"."actionId", "Post"."commentCount", ... FROM "Posts" AS "Post" INNER JOIN "Users" AS "user" ON "Post"."userId" = "user"."id" LEFT OUTER JOIN "ActivityLogs" AS "activityLog" ON "Post"."activityLogId" = "activityLog"."id" LEFT OUTER JOIN "WeightLogs" AS "weightLog" ON "Post"."weightLogId" = "weightLog"."id" LEFT …

2
วิธีจัดการกับแผนแบบสอบถามที่ไม่ดีที่เกิดจากความเท่าเทียมกันที่แน่นอนในประเภทช่วง?
ฉันกำลังอัปเดตโดยที่ฉันต้องการความเท่าเทียมกันแน่นอนในtstzrangeตัวแปร แถว ~ 1M มีการแก้ไขและแบบสอบถามใช้เวลาประมาณ 13 นาที ผลลัพธ์ของEXPLAIN ANALYZEสามารถเห็นได้ที่นี่และผลลัพธ์ที่แท้จริงแตกต่างอย่างมากจากที่ประเมินโดยผู้วางแผนแบบสอบถาม ปัญหาคือการสแกนดัชนีt_rangeคาดว่าจะส่งคืนแถวเดียว สิ่งนี้น่าจะเกี่ยวข้องกับความจริงที่ว่าสถิติของประเภทช่วงนั้นถูกจัดเก็บแตกต่างจากประเภทอื่น ๆ มองไปที่pg_statsมุมมองสำหรับคอลัมน์ที่n_distinctเป็น -1 และสาขาอื่น ๆ (เช่นmost_common_vals, most_common_freqs) เป็นที่ว่างเปล่า อย่างไรก็ตามจะต้องมีสถิติเก็บไว้ในt_rangeบางแห่ง การอัปเดตที่คล้ายกันอย่างยิ่งซึ่งฉันใช้ 'ภายใน' บน t_range แทนที่จะใช้ความเท่าเทียมกันที่แน่นอนใช้เวลาประมาณ 4 นาทีในการดำเนินการและใช้แผนคิวรีที่แตกต่างกันอย่างมาก (ดูที่นี่ ) แผนคิวรีที่สองนั้นสมเหตุสมผลสำหรับฉันเพราะทุกแถวในตาราง temp และส่วนสำคัญของตารางประวัติจะถูกนำมาใช้ t_rangeที่สำคัญกว่าการวางแผนแบบสอบถามคาดการณ์ตัวเลขให้ถูกต้องประมาณแถวสำหรับกรอง การกระจายตัวของt_rangeมันค่อนข้างผิดปกติ ฉันใช้ตารางนี้เพื่อเก็บสถานะทางประวัติศาสตร์ของตารางอื่นและการเปลี่ยนแปลงของตารางอื่น ๆ เกิดขึ้นพร้อมกันในการทิ้งขนาดใหญ่ดังนั้นจึงมีค่าที่แตกต่างกันไม่มากt_rangeนัก นี่คือการนับที่สอดคล้องกับค่าที่ไม่ซ้ำกันของt_range: t_range | count -------------------------------------------------------------------+--------- ["2014-06-12 20:58:21.447478+00","2014-06-27 07:00:00+00") | 994676 ["2014-06-12 20:58:21.447478+00","2014-08-01 01:22:14.621887+00") …

4
การอัพเดตแถวด้วยค่าเดียวกันอัพเดตแถวจริงหรือไม่?
ฉันมีคำถามเกี่ยวกับประสิทธิภาพ สมมติว่าฉันมีผู้ใช้ชื่อ Michael ใช้แบบสอบถามต่อไปนี้: UPDATE users SET first_name = 'Michael' WHERE users.id = 123 แบบสอบถามจะดำเนินการอัปเดตจริงหรือไม่แม้ว่าจะมีการอัปเดตเป็นค่าเดียวกันหรือไม่ ถ้าเป็นเช่นนั้นฉันจะป้องกันไม่ให้เกิดขึ้นได้อย่างไร

1
การเพิ่มประสิทธิภาพดัชนีพร้อมวันที่
คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Exchange Administrators Stack Exchange อพยพ 7 ปีที่ผ่านมา ฉันมีตารางวัตถุขนาดใหญ่ (แถว 15M +) ใน PostgreSQL 9.0.8 ซึ่งฉันต้องการค้นหาเขตข้อมูลที่ล้าสมัย ฉันต้องการแบ่งคำถามเป็นล้าน ๆ เพื่อความยืดหยุ่นในการปรับขนาดและการทำงานพร้อมกันและฉันต้องการดึงข้อมูลทั้งหมดด้วยฟิลด์ updated_at ด้วยวันที่ไม่กี่วันที่ผ่านมา ฉันได้ลองใช้ดัชนีจำนวนมากและข้อความค้นหาหลายล้านรายการและดูเหมือนว่าฉันจะไม่สามารถทำงานได้ภายใน 100 วินาทีด้วยฮาร์ดแวร์ Ronin ของ Heroku ฉันกำลังมองหาคำแนะนำที่ฉันไม่ได้พยายามทำให้มีประสิทธิภาพมากที่สุด ลอง # 1 EXPLAIN ANALYZE SELECT count(*) FROM objects WHERE (date(updated_at)) < (date(now())-7) AND id >= 5000001 AND id …

1
ดัชนี: จำนวนเต็มกับประสิทธิภาพของสตริงถ้าจำนวนโหนดเท่ากัน
ฉันกำลังพัฒนาแอพพลิเคชั่นใน Ruby on Rails ด้วยฐานข้อมูล PostgreSQL (9.4) สำหรับกรณีการใช้งานของฉันคอลัมน์ในตารางจะถูกค้นหาบ่อยมากเนื่องจากทั้งจุดของแอปพลิเคชันกำลังค้นหาแอตทริบิวต์ที่เฉพาะเจาะจงมากในแบบจำลอง ฉันกำลังตัดสินใจว่าจะใช้integerชนิดหรือเพียงแค่ใช้ประเภทสตริงทั่วไป (เช่นcharacter varying(255), ซึ่งเป็นค่าเริ่มต้นใน Rails ) สำหรับคอลัมน์ที่เป็นผมไม่แน่ใจว่าสิ่งที่แตกต่างของประสิทธิภาพการทำงานจะอยู่ในดัชนี คอลัมน์เหล่านี้เป็น enums มีขนาดคงที่สำหรับจำนวนค่าที่เป็นไปได้ที่สามารถมีได้ ส่วนใหญ่ความยาว enum ไม่เกิน 5 หมายถึงดัชนีจะมีมากขึ้นหรือน้อยคงที่ตลอดอายุการใช้งานของโปรแกรม ; ดังนั้นจำนวนเต็มและดัชนีสตริงจะเหมือนกันในจำนวนโหนด อย่างไรก็ตามสตริงที่จะทำดัชนีอาจมีความยาวประมาณ 20 ตัวอักษรซึ่งในหน่วยความจำประมาณ 5x ของจำนวนเต็ม (ถ้าจำนวนเต็ม 4 ไบต์และสตริงนั้นเป็น ASCII บริสุทธิ์ที่ 1 ไบต์ต่อตัวอักษรดังนั้นสิ่งนี้จะเก็บไว้) ฉันไม่รู้ว่าเอ็นจิ้นฐานข้อมูลทำการค้นหาดัชนีอย่างไร แต่ถ้ามันจำเป็นต้อง "สแกน" สตริงจนกว่าจะตรงกันทั้งหมดดังนั้นในสาระสำคัญซึ่งหมายความว่าการค้นหาสตริงจะช้ากว่าการค้นหาจำนวนเต็ม 5 เท่า "สแกน" จนกระทั่งตรงกับการค้นหาจำนวนเต็มจะเป็น 4 ไบต์แทน 20 นี่คือสิ่งที่ฉันจินตนาการ ค่าการค้นหาคือ …

5
เลือก DISTINCT ในหลายคอลัมน์
สมมติว่าเรามีตารางที่มีสี่คอลัมน์(a,b,c,d)ของชนิดข้อมูลเดียวกัน เป็นไปได้หรือไม่ที่จะเลือกค่าที่แตกต่างทั้งหมดภายในข้อมูลในคอลัมน์และส่งกลับเป็นคอลัมน์เดียวหรือฉันต้องสร้างฟังก์ชันเพื่อให้ได้สิ่งนี้?

1
การเรียกใช้ VACUUM บนโต๊ะที่รับเฉพาะ INSERT นั้นคุ้มค่าหรือไม่
ในปี 2558 เรื่องการประดิษฐ์คิดค้น AWS กล่าวว่าเครื่องดูดฝุ่นควรทำงานไม่เพียง แต่หลังจากการปรับปรุงหรือลบ แต่ยังหลังจากการแทรก นี่คือส่วนที่เกี่ยวข้องของการพูดคุย: http://www.youtube.com/watch?v=tZXp19q8RFo&t=16m2s สมมุติว่ามีการล้างข้อมูลที่ต้องทำบนบล็อกแม้ว่าจะได้รับการแทรกเท่านั้นและการล้างข้อมูลนี้สามารถทำได้ทั้งในครั้งแรกที่มีการเลือกบล็อก (ชะลอการอ่าน) หรือระหว่างการดูด สิ่งนี้เป็นจริงหรือไม่และหากเป็นเช่นนั้นการล้างข้อมูลต้องทำอย่างไร

1
log_min_duration_statement การตั้งค่าจะถูกละเว้น
ฉันกำลังทำงานPostgresql 9.1บน Ubuntu รุ่น Postgresql ที่แน่นอน9.1+129ubuntu1เป็นตัวจัดการแพคเกจของฉันแสดง ฉันมี 2 ฐานข้อมูลที่ใช้งานอยู่และถูกใช้จากเซิร์ฟเวอร์ระยะไกล ฉันต้องการบันทึกการสืบค้นที่มีเวลาดำเนินการนาน ดังนั้นฉันจึงตั้งค่าพารามิเตอร์ต่อไปนี้ใน/etc/postgresql/9.1/main/postgresql.confไฟล์ log_min_duration_statement = 10000 log_statement = 'mod' ดังนั้น Postgresql จะบันทึกการสืบค้นที่ใช้เวลานานกว่า 10 วินาที แต่เมื่อฉันreloadกำหนดค่า postgres, Postgresql เริ่มบันทึกทุกแบบสอบถามที่เหมาะกับlog_statementค่า ที่ฉันตั้งค่าระยะเวลาเป็น 100 วินาทีเพื่อให้แน่ใจ log_min_duration_statement = 100000 แต่ Postgresql จะทำการบันทึกทุกข้อความค้นหาที่ตรงกับlog_statementค่าโดยไม่คำนึงถึงlog_min_duration_statementคุณค่า การตั้งค่าlog_statementที่จะnoneลำบากในการเข้าสู่ระบบหยุด มีบางอย่างที่ฉันพลาดเกี่ยวกับการกำหนดค่าหรือไม่

1
ทำไม LEFT JOIN นี้ถึงทำงานแย่กว่า LEAT JOIN LATERAL มากนัก?
ฉันมีตารางต่อไปนี้ (นำมาจากฐานข้อมูล Sakila): film: film_id คือ pkey นักแสดง: actor_id คือกุญแจ film_actor: film_id และ actor_id เป็น fkeys สำหรับภาพยนตร์ / นักแสดง ฉันกำลังเลือกภาพยนตร์เฉพาะเรื่อง สำหรับหนังเรื่องนี้ฉันต้องการให้นักแสดงทุกคนเข้าร่วมในภาพยนตร์เรื่องนี้ด้วย ฉันมีสองคำสั่งสำหรับการนี้: หนึ่งที่มีและเป็นหนึ่งเดียวกับLEFT JOINLEFT JOIN LATERAL select film.film_id, film.title, a.actors from film left join ( select film_actor.film_id, array_agg(first_name) as actors from actor inner join film_actor using(actor_id) group by film_actor.film_id ) …

2
วิธีเพิ่มความเร็วในการเรียงลำดับโดยการเรียงลำดับเมื่อใช้ดัชนี GIN ใน PostgreSQL
ฉันมีโต๊ะแบบนี้: CREATE TABLE products ( id serial PRIMARY KEY, category_ids integer[], published boolean NOT NULL, score integer NOT NULL, title varchar NOT NULL); ผลิตภัณฑ์สามารถเป็นของหลายหมวดหมู่ category_idsคอลัมน์เก็บรายการรหัสประจำตัวของหมวดหมู่ผลิตภัณฑ์ทั้งหมด ข้อความค้นหาทั่วไปจะมีลักษณะดังนี้ (ค้นหาหมวดหมู่เดียวเสมอ): SELECT * FROM products WHERE published AND category_ids @> ARRAY[23465] ORDER BY score DESC, title LIMIT 20 OFFSET 8000; เพื่อเพิ่มความเร็วฉันใช้ดัชนีต่อไปนี้: CREATE INDEX idx_test1 …

2
สแกนดัชนีช้าในตารางขนาดใหญ่
ใช้ PostgreSQL 9.2 ฉันมีปัญหากับการสืบค้นที่ช้าในตารางที่ค่อนข้างใหญ่ (200+ ล้านแถว) ฉันไม่ได้พยายามอะไรที่บ้าคลั่งเพียงแค่เพิ่มคุณค่าทางประวัติศาสตร์ ด้านล่างคือแบบสอบถามและผลลัพธ์แผนแบบสอบถาม เค้าโครงตารางของฉัน: Table "public.energy_energyentry" Column | Type | Modifiers -----------+--------------------------+----------------------------------------------------------------- id | integer | not null default nextval('energy_energyentry_id_seq'::regclass) prop_id | integer | not null timestamp | timestamp with time zone | not null value | double precision | not null Indexes: "energy_energyentry_pkey" PRIMARY …

1
pgAdmin ช้ามากในการดำเนินการทางไกล
ฉันเรียกใช้แบบสอบถามนี้จาก pgAdmin ท้องถิ่นของฉันเชื่อมต่อจากระยะไกลไปยังเซิร์ฟเวอร์ dev ของเรา: select * from users order by random() limit 1; แฮงค์เป็นเวลา17วินาทีและแสดงให้เห็น Total query runtime: 148 ms. 1 row retrieved. มันยังค้างอยู่บนการดำเนินการใด ๆ แม้แต่คลิกขวาบนโต๊ะ Afterwise ฉันเชื่อมต่อผ่าน RDP และเรียกใช้แบบสอบถามเดียวกันมีในรุ่น pgAdmin query time: 32 msเดียวกันซึ่งแสดงผลทันทีด้วย จากนั้นฉันเรียกใช้แบบสอบถามจาก pgAdmin ท้องถิ่นของฉันอีกครั้ง: Total query runtime: 337 ms. 1 row retrieved. ฉันมี ping 130 ms …

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.