选择不同。最合适的技术来减少等待时间

我每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

它不必扫描整个表格。它可能会做得很好，但它也没有。 –

是的。但是，它必须扫描整个索引。但是你是对的，如果这个指数很小，那会让它变得更快。 –

选择不同。最合适的技术来减少等待时间

回答

相关问题