Скопируйте таблицу (включая индексы) в пост-ГРЭС

[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 имеет патч для устранения проблем табличной области, если второй метод используется

у меня есть таблица пост-ГРЭС. Я должен удалить некоторые данные из него.

я предполагаю это...

delete from yourtable
where <condition(s)>

... не будет работать по некоторым причинам. (Хотите совместно использовать ту причину?)

я собирался составить временную таблицу, скопировать данные в, воссоздать индексы и удаление строк, в которых я нуждаюсь.

Изучают pg_dump и pg_restore. Используя pg_dump с некоторыми умными опциями и возможно редактированием вывода, прежде чем pg_restoring мог бы добиться цели.

, Так как Вы делаете, "что, если" - анализ типа данных, интересно, мог ли бы Вы быть более обеспеченными представлениями использования.

Вы могли определить представление для каждого сценария, который Вы хотите протестировать на основе отрицания того, что Вы хотите исключить. Т.е. определите представление на основе того, что Вы хотите Включать. Например, если Вы хотите "окно" на данных, где Вы "удалили" строки, где X=Y, тогда Вы создадите представление как строки где (X! = Y).

Представления хранятся в базе данных (в Системном каталоге) как их запрос определения. Каждый раз, когда Вы запрашиваете представление, сервер базы данных ищет базовый запрос, который определяет его и выполняет это (ANDed с любыми другими условиями, которые Вы использовали). Существует несколько преимуществ для этого подхода:

1. Вы никогда не копируете части своих данных.
2. индексы, уже используемые для базовой таблицы (Ваша исходная, "реальная" таблица), будут использоваться (как сочтено целесообразным оптимизатором запросов) при запросах каждого представления/сценария. Нет никакой потребности переопределить или скопировать их.
3. , Так как представление является "окном" (НЕ shapshot) на "реальных" данных в базовой таблице, можно добавить/обновить/удалить на базовой таблице и просто повторно запросить сценарии представления без потребности воссоздать что-либо, поскольку данные изменяются со временем.

существует компромисс, конечно. Так как представление является виртуальной таблицей и не "реальной" (основной) таблицей, Вы на самом деле выполняетесь (возможно, комплекс) запрашивают каждый раз, когда Вы получаете доступ к нему. Это может замедлить вещи немного. Но это не может. Это зависит от многих проблем (размер и характер данных, качество статистики в Системном каталоге, скорости аппаратных средств, загрузки использования, и намного больше). Вы не будете знать, пока Вы не попробуете его. Если (и только если) Вы на самом деле находите, что производительность является неприемлемо медленной, то Вы могли бы посмотреть на другие опции. (Осуществленные представления, копии таблиц... что-либо, что торгует пространством в течение времени.)

Составьте новую таблицу с помощью выбора для захвата данных, которые Вы хотите. Тогда подкачайте старую таблицу с новой.

create table mynewone as select * from myoldone where ...
mess (re-create) with indexes after the table swap.

Новый PostgreSQL (начиная с версии 8.3 согласно документации) может использовать "ВКЛЮЧАЯ ИНДЕКСЫ":

# 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)