選擇不同。最合適的技術來減少等待時間

我每20分鐘在此表中插入一次，每天清除舊的條目，並且只有2個選擇選項。

所以我想優化時間，我等待我的選擇。

首先選擇一種：

Select * from table where item=<item_id>

二是怎麼樣的：

Select distinct(datetime) from table

因此，爲了優化1個選擇，我可能會讓indexies爲item領域。正如我所理解的，這項技術完美適用於那些不適合查詢的地方。

但我不知道如何優化我的2選擇查詢。我認爲像劃分應該幫助我，但有幾種類型的分區，我有點困惑。

那麼優化我的查詢的最佳選擇是什麼？

此外，我正在使用python和Django模型。如果有一個好的圖書館可以完成所有骯髒的工作。那太好了。現在最合適的，我發現：http://architect.readthedocs.io/

編輯1 感謝埃文卡羅爾。

試圖對第二個查詢使用索引。命令：

explain analyze select distinct time_updated from wow_auction_gordunni

給出：

HashAggregate (cost=335091.65..335092.51 rows=86 width=8) (actual time=4246.582..4246.607 rows=91 loops=1) 
    Group Key: time_updated 
    -> Seq Scan on wow_auction_gordunni (cost=0.00..313574.92 rows=8606692 width=8) (actual time=0.047..2257.979 rows=8616562 loops=1) 
Planning time: 0.080 ms 
Execution time: 4246.675 ms

然後創建索引和真空：

Create INDEX ON wow_auction_gordunni (time_updated); 
VACUUM ANALYZE wow_auction_gordunni; 
explain analyze select distinct time_updated from wow_auction_gordunni;

給出如下：

Unique (cost=0.43..249907.42 rows=92 width=8) (actual time=0.057..3537.626 rows=92 loops=1) 
    -> Index Only Scan using wow_auction_gordunni_time_updated_idx on wow_auction_gordunni (cost=0.43..228163.42 rows=8697599 width=8) (actual time=0.055..2488.408 rows=8696562 loops=1) 
     Heap Fetches: 85796 
Planning time: 0.726 ms 
Execution time: 3537.800 ms

如此看來，指數有點幫助（postgres sta被用來使用指數），但不是顯着。

來源

2017-03-03 Snobby

只要有意義，它將使用索引掃描。樣本數據，

CREATE TABLE foo 
AS 
    SELECT 
    x%3 AS x, 
    repeat(md5(x::text)::text, 200) AS t1 
    FROM generate_series(1,1e6) AS t(x); 

CREATE INDEX ON foo (x); 
VACUUM ANALYZE foo;

查詢，

EXPLAIN ANALYZE SELECT DISTINCT x FROM Foo; 
                   QUERY PLAN                 
--------------------------------------------------------------------------------------------------------------------------------------------- 
Unique (cost=0.42..28480.42 rows=200 width=32) (actual time=0.034..257.734 rows=3 loops=1) 
    -> Index Only Scan using foo_x_idx on foo (cost=0.42..25980.42 rows=1000000 width=32) (actual time=0.031..122.668 rows=1000000 loops=1) 
     Heap Fetches: 0 
Planning time: 0.090 ms 
Execution time: 257.764 ms 
(5 rows)

因此，要優化你的第二個選擇查詢，創建日期時間的索引。檢查出EXPLAIN ANALYZE。看看它是否使用索引。如果這沒有幫助或索引未被使用，您可以嘗試set enable_seqscan = off，然後重新運行查詢。現在你知道節省的錢是多少，如果有的話。你可以在這裏粘貼這兩個計劃，我們可以看看它。

來源

2017-03-03 17:16:09

如果PostgreSQL *知道*索引中的幾乎所有元組都對所有人都可見，那麼只有當表最近已經被清空並沒有什麼改變時，它纔會起作用。 –

感謝您的命令。「解析分析」命令後，不知道「真空分析」以及數據是什麼。將挖掘他們，並嘗試這一天。 – Snobby

試圖做一個索引。更新的問題。它有幫助，但不是很多。 – Snobby

沒有辦法優化第二個查詢，它必須掃描整個表以找到所有可能的值datetime。

您可以做的最好的辦法是通過清除表格TRUNCATE而不是DELETE，並將足夠的RAM放入機器以使整個表格位於RAM中，從而確保表格不臃腫。

來源

2017-03-03 15:42:25

它不必掃描整個表格。它可能會做得很好，但它也沒有。 –

是的。但是，它必須掃描整個索引。但是你是對的，如果這個指數很小，那會讓它變得更快。 –

選擇不同。最合適的技術來減少等待時間

回答

相關問題