बेंचमार्क
9.4 और 9.5 के साथ सबसे दिलचस्प उम्मीदवारों का परीक्षण के एक आधे रास्ते यथार्थवादी तालिका के साथ 200k पंक्तियों में purchases
और 10k अलगcustomer_id
( औसत। प्रति ग्राहक 20 पंक्तियों )।
पोस्टग्रैज 9.5 के लिए मैंने 86446 अलग-अलग ग्राहकों के साथ एक दूसरा परीक्षण किया। नीचे देखें ( औसत ग्राहक प्रति 2.3 पंक्तियाँ )।
सेट अप
मुख्य तालिका
CREATE TABLE purchases (
id serial
, customer_id int -- REFERENCES customer
, total int -- could be amount of money in Cent
, some_column text -- to make the row bigger, more realistic
);
मैं एक serial
(पीके बाधा नीचे जोड़ा गया) और एक पूर्णांक का उपयोग करता हूं customer_id
क्योंकि यह एक अधिक विशिष्ट सेटअप है। को भी जोड़ाsome_column
आम तौर पर अधिक स्तंभों के लिए बनाने के लिए गया।
डमी डेटा, पीके, इंडेक्स - एक विशिष्ट तालिका में कुछ मृत ट्यूपल भी हैं:
INSERT INTO purchases (customer_id, total, some_column) -- insert 200k rows
SELECT (random() * 10000)::int AS customer_id -- 10k customers
, (random() * random() * 100000)::int AS total
, 'note: ' || repeat('x', (random()^2 * random() * random() * 500)::int)
FROM generate_series(1,200000) g;
ALTER TABLE purchases ADD CONSTRAINT purchases_id_pkey PRIMARY KEY (id);
DELETE FROM purchases WHERE random() > 0.9; -- some dead rows
INSERT INTO purchases (customer_id, total, some_column)
SELECT (random() * 10000)::int AS customer_id -- 10k customers
, (random() * random() * 100000)::int AS total
, 'note: ' || repeat('x', (random()^2 * random() * random() * 500)::int)
FROM generate_series(1,20000) g; -- add 20k to make it ~ 200k
CREATE INDEX purchases_3c_idx ON purchases (customer_id, total DESC, id);
VACUUM ANALYZE purchases;
customer
तालिका - बेहतर क्वेरी के लिए
CREATE TABLE customer AS
SELECT customer_id, 'customer_' || customer_id AS customer
FROM purchases
GROUP BY 1
ORDER BY 1;
ALTER TABLE customer ADD CONSTRAINT customer_customer_id_pkey PRIMARY KEY (customer_id);
VACUUM ANALYZE customer;
9.5 के लिए अपने दूसरे परीक्षण में मैंने एक ही सेटअप का उपयोग किया, लेकिन प्रति कुछ ही पंक्तियों को प्राप्त करने के random() * 100000
लिए उत्पन्न customer_id
करने के लिएcustomer_id
।
तालिका के लिए ऑब्जेक्ट आकार purchases
इस क्वेरी के साथ जनरेट किया गया ।
what | bytes/ct | bytes_pretty | bytes_per_row
-----------------------------------+----------+--------------+---------------
core_relation_size | 20496384 | 20 MB | 102
visibility_map | 0 | 0 bytes | 0
free_space_map | 24576 | 24 kB | 0
table_size_incl_toast | 20529152 | 20 MB | 102
indexes_size | 10977280 | 10 MB | 54
total_size_incl_toast_and_indexes | 31506432 | 30 MB | 157
live_rows_in_text_representation | 13729802 | 13 MB | 68
------------------------------ | | |
row_count | 200045 | |
live_tuples | 200045 | |
dead_tuples | 19955 | |
प्रश्नों
WITH cte AS (
SELECT id, customer_id, total
, row_number() OVER(PARTITION BY customer_id ORDER BY total DESC) AS rn
FROM purchases
)
SELECT id, customer_id, total
FROM cte
WHERE rn = 1;
2. row_number()
वश में (मेरा अनुकूलन)
SELECT id, customer_id, total
FROM (
SELECT id, customer_id, total
, row_number() OVER(PARTITION BY customer_id ORDER BY total DESC) AS rn
FROM purchases
) sub
WHERE rn = 1;
SELECT DISTINCT ON (customer_id)
id, customer_id, total
FROM purchases
ORDER BY customer_id, total DESC, id;
4. अधीनता के साथ rCTE LATERAL
( यहाँ देखें )
WITH RECURSIVE cte AS (
( -- parentheses required
SELECT id, customer_id, total
FROM purchases
ORDER BY customer_id, total DESC
LIMIT 1
)
UNION ALL
SELECT u.*
FROM cte c
, LATERAL (
SELECT id, customer_id, total
FROM purchases
WHERE customer_id > c.customer_id -- lateral reference
ORDER BY customer_id, total DESC
LIMIT 1
) u
)
SELECT id, customer_id, total
FROM cte
ORDER BY customer_id;
5. customer
तालिका LATERAL
( यहां देखें )
SELECT l.*
FROM customer c
, LATERAL (
SELECT id, customer_id, total
FROM purchases
WHERE customer_id = c.customer_id -- lateral reference
ORDER BY total DESC
LIMIT 1
) l;
SELECT (array_agg(id ORDER BY total DESC))[1] AS id
, customer_id
, max(total) AS total
FROM purchases
GROUP BY customer_id;
परिणाम
उपरोक्त प्रश्नों के लिए निष्पादन समय EXPLAIN ANALYZE
(और सभी विकल्प बंद ), सर्वश्रेष्ठ 5 रन ।
सभी प्रश्नों ने एक सूचकांक केवल स्कैन पर उपयोग कियाpurchases2_3c_idx
(अन्य कदम के अलावा)। उनमें से कुछ सिर्फ सूचकांक के छोटे आकार के लिए, दूसरों को अधिक प्रभावी ढंग से।
A. 200k पंक्तियों के साथ 9.4 और ~ 20 प्रति पोस्टग्रे customer_id
1. 273.274 ms
2. 194.572 ms
3. 111.067 ms
4. 92.922 ms
5. 37.679 ms -- winner
6. 189.495 ms
B. पोस्टग्रेज 9.5 के साथ भी ऐसा ही है
1. 288.006 ms
2. 223.032 ms
3. 107.074 ms
4. 78.032 ms
5. 33.944 ms -- winner
6. 211.540 ms
C. बी के समान, लेकिन ~ 2.3 पंक्तियों प्रति के साथ customer_id
1. 381.573 ms
2. 311.976 ms
3. 124.074 ms -- winner
4. 710.631 ms
5. 311.976 ms
6. 421.679 ms
संबंधित बेंचमार्क
यहाँ "OGR" के साथ परीक्षण करके एक नया है 10M पंक्तियों और 60k अद्वितीय "ग्राहकों" पर Postgres 11.5 (सितम्बर 2019 के रूप में वर्तमान)। परिणाम अभी भी हम क्या देखा है के साथ लाइन में हैं:
2011 से मूल (पुराना) बेंचमार्क
मैंने 65579 पंक्तियों की एक वास्तविक जीवन तालिका पर पोस्टग्रेसीक्यू 9.1 के साथ तीन परीक्षण चलाए और इसमें शामिल प्रत्येक तीन स्तंभों पर एकल-स्तंभ बीटीआरई अनुक्रमित किया और 5 रन का सर्वश्रेष्ठ निष्पादन समय लिया ।
तुलना @OMGPonies ' पहली क्वेरी ( A
करने के लिए) से ऊपर DISTINCT ON
समाधान ( B
):
पूरी तालिका का चयन करें, इस मामले में 5958 पंक्तियों में परिणाम।
A: 567.218 ms
B: 386.673 ms
WHERE customer BETWEEN x AND y
1000 पंक्तियों के परिणामस्वरूप स्थिति का उपयोग करें ।
A: 249.136 ms
B: 55.111 ms
के साथ एक एकल ग्राहक का चयन करें WHERE customer = x
।
A: 0.143 ms
B: 0.072 ms
अन्य उत्तर में वर्णित सूचकांक के साथ एक ही परीक्षण दोहराया गया
CREATE INDEX purchases_3c_idx ON purchases (customer, total DESC, id);
1A: 277.953 ms
1B: 193.547 ms
2A: 249.796 ms -- special index not used
2B: 28.679 ms
3A: 0.120 ms
3B: 0.048 ms
MAX(total)
?