我有一个表，我想从中删除很多行，但由于内存限制而失败。我看到一个建议“简单地”将我不想删除的所有行复制到新表中，删除旧表，然后将新表重命名为旧表的名称。除了依赖于原始表的其他对象外，这很好。据我所知，这意味着我必须放弃级联，然后重新创建依赖于原始表的所有内容。
有没有办法编写依赖于原始表的所有内容，以便我可以轻松地在 pgadmin 或 psql 中重新创建它们？
或者，有没有办法忽略依赖关系足够长的时间来删除旧表并将新表重命名为旧表的名称？
我相信这就是 pg_repack 的工作方式，所以一定有办法。
所以我有 Ubuntu 14.04 和 postgres 9.6 我想安装 pg_repack 所以我做了
sudo apt-get install pgxnclient`
sudo pgxn install pg_repack
但我遇到了一个错误（对不起，我忘记了错误），我发现一个网站说我需要
sudo apt-get install postgresql-server-dev-all
sudo apt-get install postgresql-common
我怀疑其中一个或两个都是作为 Postgresql 10 出现的，因为当我这样做时
sudo pgxn install pg_repack
它似乎可以工作，只是在/usr/lib/postgresql/10/bin我仍在运行 9.6 服务器时将文件放入其中。
我可以将它移动/usr/lib/postgresql/9.6/bin到 postgres10 还是有一些特定的东西如果我只是移动它就不起作用？
其次，如何配置pgxn为使用 9.6 而不是 10？
这里的网站已经死了，所以我想那里有我无法获得的文档。
假设我想要CLUSTER一张桌子。无法知道需要多长时间，所以我只是运行它。几个小时后，我需要数据，所以我取消了CLUSTER命令。CLUSTERing 是否与临时表/文件一起工作，这样如果我在它完成之前取消，所有这些都将被删除并且它运行的时间被浪费或者它是否使更改“实时”以便在几个小时后取消并不是完全浪费时间？
我正在运行我的 postgres 9.4 DB 的 pg_dump，如果其他进程在表上具有排他锁，它偶尔会遇到错误。有没有办法让 pg_dump 忽略该表并继续处理数据库的其余部分，而不是仅仅停止在其轨道上？
我有一个大约 100M 行的表。它每天只插入一次数据，但我们需要做select很多事情。这些selects 通常很简单，但有时需要返回数千行的数百行。
它基于三列node_id,是唯一的pricedate，hour分别是 integer, timestamp, integer。对于大多数查询来说它很慢，但我将它聚集到node_id，pricedate这解决了大多数查询的缓慢问题。这些查询属于以下类型：
select * from mytable where node_id in (1,2,3,4)
我们仍然偶尔需要做这样的查询：
select * from mytable where pricedate>='2016-05-01'
这些仍然很慢，因为它node_id首先聚集在一起。我们已经有了索引pricedate。问题是用户经常需要足够的数据，以至于查询引擎抛出索引并使用 seq 扫描。一旦它使用序列扫描，它就会从以查询方式聚集数据中获益匪浅。这导致了我遇到的问题，其中一些查询受益于一个集群，而其他查询受益于另一个集群：
如果有一种方法可以拥有表的两个物理副本，其中一个副本以一种方式聚集，另一个以另一种方式聚集，但用户访问它似乎只有一个表，并且数据库引擎将确保它们'同步。显然这样做会有写惩罚，但这对我们的使用来说无关紧要。
这样的事情可能吗？
我猜没有内置的方法来做我描述的事情。无论如何，我想我会创建一个表mytable_dup，该表具有相同的唯一键约束但具有备用集群，然后设置触发器以在插入/更新/删除主表时插入它。这似乎是可行的，但从这里开始，是否有一种合理的方法select可以有效地从重复的表中提取出来？
我在家里运行 PostgreSQL 9.4，在 Google 上运行 9.5。
我有这张桌子：
CREATE TABLE spp.rtprices (
"interval" timestamp without time zone NOT NULL,
rtlmp numeric(12,6),
rtmcc numeric(12,6),
rtmcl numeric(12,6),
node_id integer NOT NULL,
CONSTRAINT rtprices_pkey PRIMARY KEY ("interval", node_id),
CONSTRAINT rtprices_node_id_fkey FOREIGN KEY (node_id)
REFERENCES spp.nodes (node_id) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
)
还有一个相关的索引：
CREATE INDEX rtprices_node_id_interval_idx ON spp.rtprices (node_id, "interval");
反对它我提出了这样的观点：
CREATE OR REPLACE VIEW spp.rtprices_hourly AS
SELECT (rtprices."interval" - '00:05:00'::interval)::date::timestamp without time zone AS pricedate,
date_part('hour'::text, date_trunc('hour'::text, rtprices."interval" - '00:05:00'::interval))::integer + 1 AS hour,
rtprices.node_id,
round(avg(rtprices.rtlmp), 2) AS rtlmp,
round(avg(rtprices.rtmcc), 2) AS rtmcc,
round(avg(rtprices.rtmcl), 2) AS rtmcl
FROM spp.rtprices
GROUP BY date_part('hour'::text, date_trunc('hour'::text, rtprices."interval" - '00:05:00'::interval))::integer + 1,
rtprices.node_id,
(rtprices."interval" - '00:05:00'::interval)::date::timestamp without time zone;
其重点是给出每小时数字列的平均值（时间戳每 5 分钟有一次数据）。问题在于，对于 24 条记录，一天的查询node_id需要超过 30 秒的时间。
explain analyze select * from spp.rtprices_hourly
where node_id=20 and pricedate='2015-02-02'
返回这个：
"HashAggregate (cost=1128767.71..1128773.79 rows=135 width=28) (actual time=31155.023..31155.065 rows=24 loops=1)"
" Group Key: ((date_part('hour'::text, date_trunc('hour'::text, (rtprices."interval" - '00:05:00'::interval))))::integer + 1), rtprices.node_id, (((rtprices."interval" - '00:05:00'::interval))::date)::timestamp without time zone"
" -> Bitmap Heap Scan on rtprices (cost=10629.42..1128732.91 rows=2320 width=28) (actual time=25071.410..31153.715 rows=288 loops=1)"
" Recheck Cond: (node_id = 20)"
" Rows Removed by Index Recheck: 7142233"
" Filter: (((("interval" - '00:05:00'::interval))::date)::timestamp without time zone = '2015-02-02 00:00:00'::timestamp without time zone)"
" Rows Removed by Filter: 124909"
" Heap Blocks: exact=43076 lossy=82085"
" -> Bitmap Index Scan on rtprices_node_id_interval_idx (cost=0.00..10628.84 rows=464036 width=0) (actual time=68.999..68.999 rows=125197 loops=1)"
" Index Cond: (node_id = 20)"
"Planning time: 5.243 ms"
"Execution time: 31155.392 ms"
今天早上我的数据库进入了可疑模式。我恢复到昨晚的完整备份以使其重新联机。我浏览了错误日志，发现似乎导致可疑模式的最后一个命令MERGE位于特定表上。我跑DBCC CHECKTABLE在桌子上，得到了以下信息
Msg 2511, Level 16, State 1, Line 1
Table error: Object ID 1253579504, index ID 7, partition ID 72057594230341632, alloc unit ID 72057594364887040 (type In-row data). Keys out of order on page (1:14254237), slots 184 and 185.
There are 366539002 rows in 3425599 pages for object "PJM_Prices".
CHECKTABLE found 0 allocation errors and 1 consistency errors in table 'PJM_Prices' (object ID 1253579504).
repair_rebuild is the minimum repair level for the errors found by DBCC CHECKTABLE (CaisoAnalyzer.dbo.PJM_Prices).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
在ERRORLOG
Internal database snapshot has split point LSN = 001935ad:00001bf6:0001 and first LSN = 001935ad:00001bf5:0001
有没有办法将该表置于单用户模式或其他一些技巧，我不必为整个数据库进入单用户模式？
我有一个数据库，它快要填满它所在的硬盘了。我想将数据库扩展到另一个硬盘驱动器来处理这个问题。
我看到 SSMS 下的数据库属性中有一个文件选项，我可以添加它，但我真的不想在不知道接下来会发生什么的情况下添加文件。我是否需要在文件组中添加一个新条目，然后再添加到文件中？PRIMARY 类型是否只应该用于第一个文件？如果不是，那么制作一个主要和另一个次要之间有什么区别？一旦我添加了一个文件，数据库引擎会自动决定将数据放在哪里，还是我必须进入我的表并以某种方式指定它？
抱歉，如果这是重复的。如果不是，我会感到惊讶，但我找不到另一个有这些答案的问题。