Answers:
新的PostgreSQL（根据docs 8.3开始）可以使用“ INCLUDING INDEXES”：
# select version();
version
-------------------------------------------------------------------------------------------------
PostgreSQL 8.3.7 on x86_64-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
(1 row)
如您所见，我正在8.3上进行测试。
现在，让我们创建表：
# create table x1 (id serial primary key, x text unique);
NOTICE: CREATE TABLE will create implicit sequence "x1_id_seq" for serial column "x1.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "x1_pkey" for table "x1"
NOTICE: CREATE TABLE / UNIQUE will create implicit index "x1_x_key" for table "x1"
CREATE TABLE
并查看其外观：
# \d x1
Table "public.x1"
Column | Type | Modifiers
--------+---------+-------------------------------------------------
id | integer | not null default nextval('x1_id_seq'::regclass)
x | text |
Indexes:
"x1_pkey" PRIMARY KEY, btree (id)
"x1_x_key" UNIQUE, btree (x)
现在我们可以复制结构：
# create table x2 ( like x1 INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "x2_pkey" for table "x2"
NOTICE: CREATE TABLE / UNIQUE will create implicit index "x2_x_key" for table "x2"
CREATE TABLE
并检查结构：
# \d x2
Table "public.x2"
Column | Type | Modifiers
--------+---------+-------------------------------------------------
id | integer | not null default nextval('x1_id_seq'::regclass)
x | text |
Indexes:
"x2_pkey" PRIMARY KEY, btree (id)
"x2_x_key" UNIQUE, btree (x)
如果您使用的是PostgreSQL 8.3之前的版本，则可以简单地将pg_dump与选项“ -t”一起使用来指定1个表，在转储中更改表名，然后再次加载它：
=> pg_dump -t x2 | sed 's/x2/x3/g' | psql
SET
SET
SET
SET
SET
SET
SET
SET
CREATE TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
现在的表是：
# \d x3
Table "public.x3"
Column | Type | Modifiers
--------+---------+-------------------------------------------------
id | integer | not null default nextval('x1_id_seq'::regclass)
x | text |
Indexes:
"x3_pkey" PRIMARY KEY, btree (id)
"x3_x_key" UNIQUE, btree (x)
[CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE table_name
[ (column_name [, ...] ) ]
[ WITH ( storage_parameter [= value] [, ... ] ) | WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace ]
AS query][1]
这是一个例子
CREATE TABLE films_recent AS
SELECT * FROM films WHERE date_prod >= '2002-01-01';
从第一种方法创建新表的另一种方法是使用
CREATE TABLE films_recent (LIKE films INCLUDING INDEXES);
INSERT INTO films_recent
SELECT *
FROM books
WHERE date_prod >= '2002-01-01';
请注意，如果使用第二种方法，则Postgresql会发布补丁来修复表空间问题
CREATE TABLE my_table (LIKE...)代替它CREATE TABLE my_table LIKE...才能工作。编辑答案。
我有一张postgres桌子。我需要从中删除一些数据。
我认为...
delete from yourtable
where <condition(s)>
...由于某种原因无法正常工作。（是否愿意分享这个理由？）
我打算创建一个临时表，将数据复制到其中，重新创建索引并删除所需的行。
查看pg_dump和pg_restore。使用带有一些聪明选项的pg_dump，也许在pg_restoring之前编辑输出可能会成功。
由于您正在对数据进行“假设”类型分析，因此我想知道使用视图是否会更好。
您可以根据要排除的内容的否定为每个要测试的方案定义一个视图。即，根据您要包含的内容定义视图。例如，如果要在“删除” X = Y的行的数据上创建“窗口”，则可以将视图创建为其中（X！= Y）的行。
视图作为定义查询存储在数据库中（系统目录中）。每次查询视图时，数据库服务器都会查询定义该视图的基础查询并执行该查询（与您使用的任何其他条件进行“与”操作）。这种方法有几个好处：
当然，需要权衡取舍。由于视图是虚拟表，而不是“真实”（基本）表，因此，每次访问它时，您实际上是在执行一个（也许很复杂的）查询。这可能会使速度变慢。但事实并非如此。它取决于许多问题（数据的大小和性质，系统目录中统计信息的质量，硬件的速度，使用负载等）。除非您尝试一下，否则您不会知道。如果（且仅）当您实际上发现性能降低到令人无法接受的程度，那么您可能会考虑其他选择。（材料化的视图，表的副本，等等。。。