相关疑难解决方法(0)

我在 Ubuntu 12.04 上使用 PostgreSQL 9.1。

我需要在一个时间范围内选择记录：我的表time_limits有两个timestamp字段和一个integer属性。我的实际表中还有其他列与此查询无关。

create table (
   start_date_time timestamp,
   end_date_time timestamp, 
   id_phi integer, 
   primary key(start_date_time, end_date_time,id_phi);

该表包含大约 200 万条记录。

像下面这样的查询花费了大量的时间：

select * from time_limits as t 
where t.id_phi=0 
and t.start_date_time <= timestamp'2010-08-08 00:00:00'
and t.end_date_time   >= timestamp'2010-08-08 00:05:00';

所以我尝试添加另一个索引 - PK的倒数：

create index idx_inversed on time_limits(id_phi, start_date_time, end_date_time);

我的印象是性能有所提高：访问表中间记录的时间似乎更合理：介于 40 到 90 秒之间。

但是对于时间范围中间的值，它仍然是几十秒。在针对表格末尾时（按时间顺序），还有两次。

我explain analyze第一次尝试得到这个查询计划：

 Bitmap Heap Scan on time_limits  (cost=4730.38..22465.32 rows=62682 width=36) (actual time=44.446..44.446 rows=0 loops=1)
   Recheck …

我们的系统写入了大量数据（一种大数据系统）。写入性能足以满足我们的需求，但读取性能真的太慢了​​。

我们所有表的主键（约束）结构都相似：

timestamp(Timestamp) ; index(smallint) ; key(integer).

一个表可以有数百万行，甚至数十亿行，而一个读请求通常是针对特定时间段（时间戳/索引）和标记的。查询返回大约 20 万行是很常见的。目前，我们每秒可以读取大约 15k 行，但我们需要快 10 倍。这是可能的，如果是，如何？

注意： PostgreSQL 是和我们的软件一起打包的，所以不同客户端的硬件是不一样的。

它是一个用于测试的虚拟机。VM 的主机是具有 24.0 GB RAM 的 Windows Server 2008 R2 x64。

服务器规范（虚拟机 VMWare）

Server 2008 R2 x64
2.00 GB of memory
Intel Xeon W3520 @ 2.67GHz (2 cores)

postgresql.conf 优化

shared_buffers = 512MB (default: 32MB)
effective_cache_size = 1024MB (default: 128MB)
checkpoint_segment = 32 (default: 3)
checkpoint_completion_target = 0.9 (default: 0.5)
default_statistics_target = 1000 (default: 100)
work_mem = 100MB (default: 1MB)
maintainance_work_mem = 256MB …

我正在研究 PostgreSQL 数据库设计，我想知道如何最好地存储时间戳。

假设

不同时区的用户将使用数据库执行所有 CRUD 功能。

我查看了 2 个选项：

• timestamp NOT NULL DEFAULT (now() AT TIME ZONE 'UTC')

• bigint NOT NULL DEFAULT

因为timestamp我会发送一个字符串来表示 INSERT 时刻的确切（UTC）时间戳。

因为bigint我会存储完全相同的东西，但以数字格式存储。（时区问题是在将毫秒移交给服务器之前处理的，因此总是以 UTC 为单位的毫秒。）

存储 a 的一个主要优点bigint可能是它更容易存储和检索，因为传递正确格式的时间戳比简单的数字（自 Unix Epoc 以来的毫秒）更复杂。

我的问题是哪种方法可以实现最灵活的设计，以及每种方法可能存在哪些缺陷。

我有一张桌子articles：

                                                       Table "articles"
     Column     |            Type             |                     Modifiers                      | Storage  | Stats target | Description
----------------+-----------------------------+----------------------------------------------------+----------+--------------+-------------
 id             | integer                     | not null default nextval('articles_id_seq'::regclass) | plain    |              |
 user_id        | integer                     |                                                    | plain    |              |
 title          | character varying(255)      |                                                    | extended |              |
 author         | character varying(255)      |                                                    | extended |              |
 body           | text                        | default '--- []                                   +| extended |              |
                |                             | '::text                                            |          |              |
 created_at     | timestamp without time zone | …

我有一个未使用现有索引的查询，我不明白为什么。

桌子：

mustang=# \d+ bss.amplifier_saturation
                                               Table "bss.amplifier_saturation"
 Column |           Type           |                             Modifiers                             | Storage | Description 
--------+--------------------------+-------------------------------------------------------------------+---------+-------------
 value  | integer                  | not null                                                          | plain   | 
 target | integer                  | not null                                                          | plain   | 
 start  | timestamp with time zone | not null                                                          | plain   | 
 end    | timestamp with time zone | not null                                                          | plain   | 
 id     | integer                  | not null default nextval('amplifier_saturation_id_seq'::regclass) | plain   | 
 lddate | timestamp with time zone | not null default …

是的，每组最多的问题。

给定一个releases包含以下列的表：

 id         | primary key                 | 
 volume     | double precision            |
 chapter    | double precision            |
 series     | integer-foreign-key         |
 include    | boolean                     | not null

我想选择音量的复合最大值，然后是一组系列的章节。

现在，如果我查询 per-distinct-series，我可以按如下方式轻松完成此操作：

SELECT 
       releases.chapter AS releases_chapter,
       releases.include AS releases_include,
       releases.series AS releases_series
FROM releases
WHERE releases.series = 741
  AND releases.include = TRUE
ORDER BY releases.volume DESC NULLS LAST, releases.chapter DESC NULLS LAST LIMIT 1;

但是，如果我有大量series（我确实有），这很快就会遇到效率问题，我要发出 100 多个查询来生成单个页面。

我喜欢滚整个事情到一个查询，在那里我可以简单地说WHERE releases.series IN (1,2,3....)，但我还没有想出如何说服Postgres的，让我这样做。

天真的方法是：

SELECT releases.volume …