标签: postgresql

我有一张表progresses（目前包含数十万条记录）：

    Column     |            Type             |                        Modifiers                        
---------------+-----------------------------+---------------------------------------------------------
 id            | integer                     | not null default nextval('progresses_id_seq'::regclass)
 lesson_id     | integer                     | 
 user_id       | integer                     | 
 created_at    | timestamp without time zone | 
 deleted_at    | timestamp without time zone | 
Indexes:
    "progresses_pkey" PRIMARY KEY, btree (id)
    "index_progresses_on_deleted_at" btree (deleted_at)
    "index_progresses_on_lesson_id" btree (lesson_id)
    "index_progresses_on_user_id" btree (user_id)

和视图v_latest_progresses，其将查询最近progress的user_id和lesson_id：

SELECT DISTINCT ON (progresses.user_id, progresses.lesson_id)
  progresses.id AS progress_id,
  progresses.lesson_id,
  progresses.user_id,
  progresses.created_at,
  progresses.deleted_at
 FROM progresses
WHERE progresses.deleted_at IS …

我希望在命令行（控制台）界面提示中显示我连接到的服务器的版本。从我在文档中读到的内容来看，可以执行 shell 命令，可以显示 psql 变量值。

这个想法是在连接上获取服务器的版本信息并在客户端的提示中使用它。我如何（在.psqlrc文件中？）在 psql 变量中分配服务器版本？

编辑：杰克道格拉斯？通过指出该\gset功能有正确的答案。结果是

show server_version
\gset
\set PROMPT1 '%:server_version: >'

谢谢你。

在我们的 PostgreSQL 9.4.4 数据库中，我们有一个每天接收大约 60 万条新记录的表。每天，每晚，我们都会从表中执行一些 ETL 导出。如果在导出之前没有分析过，真的很慢。如果我们运行ANALYZE，速度会更快，因为规划器使用具有我们查询的字段的多列索引。解决慢查询问题的首选方法是什么？我看到三个选项：

• ANALYZE 在出口之前，
• 使用自动真空/分析功能，
• 添加查询特定索引。

第二个选项要求我们指定每个表的自动清理/分析设置，因为默认设置不适用于大表。即使我们正确设置了它，也有一些边缘情况，当它仍然会引起麻烦时。例如：

autovacuum_analyze_scale_factor = 0.1

现在是默认值 - 所以如果我们的表有大约 2500 万条记录，它会在 250 万条记录后分析，这对我们来说不够频繁（我们每天有大约 60 万笔新交易）。但是，如果我们将其设置为 0.02（约 500k 条记录），则可能会发生这样的情况，对于有许多事务（例如 900k）的一天，我们将在 500k 之后运行 ANALYZE，但 400k 将保持未分析状态，这将影响查询性能。

表结构：

                                             Table "public.bet_transactions"
           Column           |            Type             |                           Modifiers
----------------------------+-----------------------------+---------------------------------------------------------------
 id                         | integer                     | not null default nextval('bet_transactions_id_seq'::regclass)
 account_id                 | integer                     | not null
 amount_cents               | integer                     | not null default 0
 money_amount_cents         | integer                     | not null default 0
 bonus_amount_cents         | integer                     | not …

我有一个包含从文本文档中提取的数据的表。数据存储在一个名为的列"CONTENT"中，我使用 GIN 创建了该索引：

CREATE INDEX "File_contentIndex"
  ON "File"
  USING gin
  (setweight(to_tsvector('english'::regconfig
           , COALESCE("CONTENT", ''::character varying)::text), 'C'::"char"));

我使用以下查询对表执行全文搜索：

SELECT "ITEMID",
  ts_rank(setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') , 
  plainto_tsquery('english', 'searchTerm')) AS "RANK"
FROM "File"
WHERE setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') 
  @@ plainto_tsquery('english', 'searchTerm')
ORDER BY "RANK" DESC
LIMIT 5;

File 表包含 250 000 行，每个"CONTENT"条目由一个随机单词和一个所有行都相同的文本字符串组成。

现在，当我搜索一个随机单词（在整个表中命中 1 个）时，查询运行得非常快（<100 毫秒）。但是，当我搜索出现在所有行中的单词时，查询运行速度非常慢（10 分钟或更长时间）。

EXPLAIN ANALYZE显示对于 1-hit 搜索，先执行位图索引扫描，然后执行位图堆扫描。对于慢速搜索，改为执行Seq Scan，这需要很长时间。

当然，在所有行中使用相同的数据是不现实的。但是由于我无法控制用户上传的文本文档，也无法控制他们执行的搜索，因此可能会出现类似的情况（搜索在 DB 中出现率很高的术语）。在这种情况下，如何提高搜索查询的性能？

运行 PostgreSQL 9.3.4

查询计划来自EXPLAIN ANALYZE：

快速搜索（在 DB …

你会使用哪个，为什么？单独的时间维度还是在事实表中放置时间戳？或者两者兼而有之？

我正在构建一个数据仓库，需要表示事件发生的时间，精确到一秒。我想汇总数据；例如，绘制一天中每小时的事件数量图。

Kimball 的“The Data Warehouse Toolkit”，有一个时间维度的设计。最近的一篇博文建议不要这样做，而是在事实表中使用时间戳：

http://www.kimballgroup.com/2004/02/design-tip-51-latest-thinking-on-time-dimension-tables/

如果我在事实表中使用时间戳，按小时汇总是否仍然容易/快速？

做出此选择时还需要考虑其他任何权衡吗？

我有一个animal带有的表name varchar(255)，并且我添加了具有以下值的行：

Piranha
__Starts With 2
Rhino
Starts With 1
0_Zebra
_Starts With 1
Antelope
_Starts With 1

当我运行此查询时：

zoology=# SELECT name FROM animal ORDER BY name;
      name       
-----------------
0_Zebra
Antelope
Piranha
Rhino
_Starts With 1
_Starts With 1
Starts With 1
__Starts With 2
(8 rows)

注意行是如何按顺序排序的，这意味着使用前导_将_Starts With 1行放在行之前Starts，但__in__Starts With 2似乎忽略了这一事实，好像2末尾比前两个字符更重要。

为什么是这样？

如果我用 Python 排序，结果是：

In  [2]: for animal in sorted(animals):
   ....:     print …

每隔几天就会遇到一些问题，postgres 崩溃并进入恢复模式。postgres 的日志看起来像这样

... Lots of this for 5-10minutes

2015-09-24 10:07:27 GMT LOG:  could not fork autovacuum worker process: Cannot allocate memory
2015-09-24 10:07:28 GMT LOG:  could not fork autovacuum worker process: Cannot allocate memory
2015-09-24 10:07:29 GMT LOG:  could not fork autovacuum worker process: Cannot allocate memory
2015-09-24 10:07:30 GMT LOG:  could not fork autovacuum worker process: Cannot allocate memory
2015-09-24 10:07:32 GMT LOG:  server process (PID 16244) was terminated by signal 9: Killed
2015-09-24 10:07:32 GMT DETAIL:  Failed …

我有一个主/从 postgresql 配置，其中从属是热备用，用作只读备份。目前，archive_command 设置为“cd”。（我读过的空话）。我的理解是archive_command可以将wal段复制到特定位置；通常我会看到使用 cp 命令将其复制到磁盘其他位置的示例。我将 wal_keep_segments 设置为 256，所以如果我理解正确的话，slave 可能会落后 wal 大约 4GB (16MB * 256) 的变化。这可能是为什么我从来不需要使用 archive_command 的原因，因为我有足够的 wal 段来解决一些滞后问题？

那么可选的 archive_command 的目的是为了保存比 wal_keep_segments 设置更多的 wal 段吗？因此，在我的情况下，数据库目录 (pg_xlog) 中将有 256 个 wal 段，并且 postgres 会在达到限制时自动轮换并清理这些 wal 段。

而且，如果我放置了一个 archive_command，它是否会继续将 wal 段保存到命令将文件复制到的任何位置（并继续添加越来越多的存档 wal 段，除非我添加了自己的清理过程）？这种想法正确吗？

那么，假设我对 archive_command 的理解是正确的，从站如何利用这些 wal 文件？从站是否首先尝试从主数据目录中检索 256 个 wal 文件，然后返回到 recovery_command 以检索早于此的 wal 文件？recovery_command 是在从站上运行还是以某种方式通过主站代理？recovery_command 的许多示例都显示它与 cp 一起使用，所以我不确定文件是如何传输到不同服务器的？

我已经尝试阅读许多关于此的指南，包括以下内容。
我什么时候必须使用 archive_command，什么时候不用 https://www.postgresql.org/docs/current/static/continuous-archiving.html

我对这些概念仍然有点模糊，并试图达到一些清晰度。有人可以澄清我上面的想法是否正确以及为什么我可以使用 archive_command 吗？谢谢阅读。

这是我的配置：

大师：postgresql.conf

listen_addresses = '*' 

wal_level = hot_standby
archive_mode = on 
max_wal_senders …

当我使用099指示 0 填充的 3 位数字时，我会在左侧得到空格。

SELECT '>' || to_char(1, '099') || '<';
 ?column? 
----------
 > 001<
(1 row)

为什么to_char这里是左填充？为什么会有前导空格？

我正在管理 PotsgreSQL 服务器，最近我意识到我的“非超级用户”用户有可能更改我为不安全密码分配的安全密码。

我在REVOKE文档中进行了搜索，但找不到阻止这种情况的方法。有可能的？

提前致谢！