相关疑难解决方法(0)

我试图理解为什么我的查询需要很长时间，即使我已经索引了所需的列：

SELECT entity_id,
       id,
       report_date
FROM own_inst_detail
WHERE ( own_inst_detail.id = 'P7M7WC-S' )
  AND ( own_inst_detail.report_date >= '2017-02-01T17:29:49.661Z' )
  AND ( own_inst_detail.report_date <= '2018-08-01T17:29:49.663Z' )

缓存结果EXPLAIN ANALYZE如下：

Bitmap Heap Scan on own_inst_detail (cost=20.18..2353.55 rows=597 width=22) (actual time=1.471..6.955 rows=4227 loops=1)
  Recheck Cond: ((id = 'P7M7WC-S'::bpchar) AND (report_date >= '2017-06-01'::date) AND (report_date <= '2018-08-01'::date))
  Heap Blocks: exact=4182
  ->  Bitmap Index Scan on own_inst_detail  (cost=0.00..20.03 rows=597 width=0) (actual time=0.901..0.901 rows=4227 loops=1)
        Index Cond: ((id = 'P7M7WC-S'::bpchar) AND (report_date >= '2017-06-01'::date) AND …

我有一个包含大约 1000 万行的表，其中包含一个主键和一个定义在其上的索引：

create table test.test_table(
    date_info date not null,
    string_data varchar(64) not null,
    data bigint
    primary key(date_info, string_data));
    create index test_table_idx 
    on test.test_table(string_data);

我有一个使用了的查询test_table_idx：

select distinct date_info from test.test_table where string_data = 'some_val';

问题是第一次运行查询最多可能需要 20 秒，而在任何后续运行中都需要 < 2 秒。

有没有办法将整个索引加载到内存中，而不是在第一次访问时获取数据库加载信息？

我正在尝试调查为什么此查询的性能如此不确定。它可能需要 1 秒到 60 秒及以上的任何时间。查询的本质是选择一个“时间窗口”，并从该时间窗口内获取所有行。

这是有问题的查询，在大约 10 亿行的表上运行：

SELECT CAST(extract(EPOCH from ts)*1000000 as bigint) as ts
    , ticks
    , quantity
    , side
FROM order_book
WHERE ts >= TO_TIMESTAMP(1618882633073383/1000000.0)
    AND ts < TO_TIMESTAMP(1618969033073383/1000000.0)
    AND zx_prod_id = 0
ORDER BY ts ASC, del desc;

这就是表的创建方式

CREATE TABLE public.order_book
(
    ts timestamp with time zone NOT NULL,
    zx_prod_id smallint NOT NULL,
    ticks integer NOT NULL,
    quantity integer NOT NULL,
    side boolean NOT NULL,
    del boolean NOT NULL
)

TO_TIMESTAMP当我走整张桌子时，其中的值将继续向前滑动。以下是EXPLAIN ANALYZE两个不同时间窗口上相同查询的输出： …

我正在使用AWS Aurora PostgreSQL Serverless自动缩放。看起来好像缩放清除了共享缓冲区，所以当我们想要提高性能时，我们被迫面对 I/O 瓶颈。在我们热身之后，我们看到了巨大的性能提升。但是，如果我们在缩放后背靠背运行，则第二次运行会更快。虽然我没有看到任何关于共享缓冲区是否在缩放时被清除的具体信息，但我几乎肯定它是。

Aurora Serverless 目前正在使用PostgreSQL 10.14，并且支持pg_prewarm扩展。它看起来像最新的文件显示在服务器重新启动后prewarm支持自动prewarm，但这是无服务器并不会出现提自动预暖的一个版本的文档中。

我发现这篇文章在重新启动服务器或从崩溃中恢复时非常适合 PostgreSQL。

1. 如果我们至少可以在缩放后保留下 ACU 节点的共享缓冲区的内容，那就没问题了。
2. 如果我们可以提前预热需要在内存中的内容，那就太棒了！
3. 有些桌子非常大，我们希望有选择地预热我们想要的作品。 pg_prewarm支持first_block和last_block阻止表/索引的编号，但是如何知道要放入哪些值呢？

我们提前知道我们的峰值是什么时候，并告诉 RDS 在此之前进行扩展，因此我们有一个可以准备的时间窗口。

我有哪些选择？