标签: postgresql

这个问题与我之前问过的问题有关：PostgreSQL 中复合索引中的列顺序（和查询顺序）

我想我可以在这里尖锐和限制我的问题，而不是超载这个问题。鉴于以下查询（和 EXPLAIN ANALYZE），我正在创建的复合索引有帮助吗？

第一个查询仅使用简单索引（大纲上的 GIST）和（pid 上的 BTREE）运行。

查询是：

EXPLAIN ANALYZE SELECT DISTINCT ON (path) oid, pid, product_name, type, path, size 
FROM portal.inventory AS inv 
WHERE ST_Intersects(st_geogfromtext('SRID=4326;POLYGON((21.51947021484375 51.55059814453125, 18.9129638671875 51.55059814453125, 18.9129638671875 48.8287353515625, 21.51947021484375 48.8287353515625, 21.51947021484375 51.55059814453125))'), inv.outline) 
AND (inv.pid in (20010,20046)) 

——

结果如下（速度更快，但也许这只是因为数据库是热的）。

"Unique  (cost=581.76..581.76 rows=1 width=89) (actual time=110.436..110.655 rows=249 loops=1)"
"  ->  Sort  (cost=581.76..581.76 rows=1 width=89) (actual time=110.434..110.477 rows=1377 loops=1)"
"        Sort Key: path"
"        Sort Method: quicksort  Memory: 242kB"
"        ->  Bitmap Heap Scan on inventory …

查看下面的示例，从第一行 ( id=9)开始，然后向下工作，选择我们尚未看到的具有's的行数限制。我们“选择”是因为我们还没有. 我们继续像这样往下工作，但是当我们到达时我们跳过它，因为我们已经有了（从行开始）。我们以同样的方式继续，我们最终停下来，因为我们已经积累了行（我们想要的限制）。4secid=9sec=1id=7sec=5id=8id=34

 id | sec
----+-----
  9 |   1  <- 1
  8 |   5  <- 2
  7 |   5  # skip, already have sec=5
  6 |   4  <- 3
  5 |   1  # skip, already have sec=1
  4 |   1  # skip, already have sec=1
  3 |   3  <- 4
  2 |   2
  1 |   1

当然，SQL算法可以（将！）与我描述的不同。

想要的结果：

 id
----
  9
  8
  6
  3 …

如何在 PostgreSQL 中打补丁？我找到了一个建议，但它似乎只适用于 *NIX。我的 PostgreSQL（9.3.1 编辑：9.3.4 现在）是从 Windows XP（32 位）上的 exe 安装程序安装的，所以我没有在建议中找到我的案例。

我现在不是在谈论次要版本升级 - 我可以通过 Stack Builder 下载安装程序，并且已经有一个关于如何处理它的很好回答的问题。但是，如果我需要一些无法通过 StackBuilder 获得的东西，或者甚至没有可执行安装程序（在我的情况下，仅在 .patch 文件中分发的补丁），我该怎么办？

我是一名使用 jpa 的 Java 开发人员，在定义我的实体中的索引之前，我想知道哪个更快或更好用？。

我们的 PostgreSQL 9.0 Windows 生产服务器空间不足。

在我们的 100GB 数据库中，我们有一个包含 TOAST 二进制数据的大表。我们删除了一些行，需要将空间归还给 O/S。

我们没有足够的空间做表的全部重写，所有我的读书CLUSTER，VACUUM FULL而且pg_repack是他们需要重写表。到目前为止，我的 google-fu 还不足以找到其他任何东西。

一些停机时间是可以接受的（约 2 小时），但是备份/恢复对于我们的目的来说太慢了，我也不热衷于在步骤之间删除数据库。

问题：如何在不进行全表重写的情况下将磁盘空间返回给 O/S？

（这是一个生产服务器，因此任何解决方案都必须有信誉/推荐/支持等）。

（PS 可以使用一个单独的更大的磁盘，如果可以以某种方式在其上重建表。表空间？）

我希望在具有许多非唯一值的字段上的大表（约 5000 万行）上创建索引。

表架构如下所示：

 Column |         Type          | Modifiers | Storage  | Stats target | Description 
--------+-----------------------+-----------+----------+--------------+-------------
 gid    | character varying(20) |           | extended |              | 
 word   | character varying(30) |           | extended |              | 
 stat   | double precision      |           | plain    |              | 
Has OIDs: no

我想在 'word' 列上创建一个索引。有一个相当规律的模式，每个单词出现大约 1000 次。我需要做快速SELECT * FROM mytable WHERE word='something';查询。在这些表上创建常规 B 树索引需要大量时间，但确实可以显着提高性能。

由于几个原因，我现在对我的解决方案感到不舒服

(1) B-Tree 索引的选择不是特别积极。是否有替代索引方案在具有高度重复值的字段上表现更好？

(2) 我在一个生产环境中，这些表相当频繁地出现和消失。因为并非所有表都会被大量查询，所以我选择只在触发某些（数据库外）应用程序时在表上构建索引，这样我知道将在表+字段上执行 10k+ 次查询。然而，在创建索引时等待 20 分钟并不理想。情况很微妙；通过创建索引获得的优化与创建索引所需的初始 time-sink 竞争。是否有“更便宜”的索引可以创建？也许整体性能比 B-Tree 稍差，但初始创建成本更低？

我有两个对象的一些数据，我想检索两个对象的最后一行，最好是在一个查询中。

表结构：

CREATE TABLE data
(
  pid serial NOT NULL,
  dt timestamp without time zone,
  object_id integer,
  info_1 numeric(10,8),
  speed numeric,
  CONSTRAINT dat_pid PRIMARY KEY (pid)
)

样本数据：

1, 2014-04-29 12:02:56, 8, ....
2, 2014-04-29 12:02:10, 8, ....
3, 2014-04-29 12:01:02, 8, ....
5, 2014-04-29 12:01:32, 6, ....
.....

我想要每个唯一的对象 ID 一行，每一行都是可用的最新行。我试图通过使用此查询来实现它，但它希望 pid 位于 group by 子句中。但我不想按 PID 分组，而是按跟踪器 ID 分组....

SELECT * 
FROM data
GROUP BY object_id

当我开始 psql 会话时，我希望已经设置了某些元命令。

例如：

\x auto
\set ON_ERROR_STOP on

我希望找到一个 rc 或配置文件，但找不到。命令行选项似乎也不全面。

我有一个返回setof record类型的函数。

CREATE TYPE CIR_TYPE AS
(
    ID integer,
    path text,
    cycle boolean
);

CREATE OR REPLACE FUNCTION circular_ref() RETURNS setof CIR_TYPE AS $body$

DECLARE
    r CIR_TYPE;

BEGIN
    For r in WITH RECURSIVE graph(ID, path, cycle) AS (
                SELECT id AS id
                     , ARRAY[parentid, id] AS path
                     , (parentid = id) AS cycle    
                FROM  mytable

                UNION ALL

                SELECT d.id, d.parentid ||path, d.parentid = ANY(path)
                FROM   graph g
                JOIN   mytable d ON d.id = g.path[1]
                WHERE  NOT g.cycle
             ) …

从文档：

在 PostgreSQL 中，行的 UPDATE 或 DELETE不会立即删除该行的旧版本[...] 但最终，任何事务都不再对过时或删除的行版本感兴趣。然后必须回收它占用的空间以供新行重用，以避免磁盘空间需求的无限增长。这是通过运行 VACUUM来完成的。

当vacuum运行时，它是否通过重写整个块来有效地释放被删除行占用的空间，或者只有当新行小于为它们让路的已删除行时，才会在新行适合可用“孔”时发生块碎片?