Archivos de restauración personalizados para restauración de la db sin los índices GIST/GINy módulos del contrib

Saludos, listeros.
Estaba leyendo un artículo de Josh Berkus en su blog(http://it.toolbox.com/blogs/database-soup/using-84-parallel-restore-with-your-83-or-82-database-31575) sobre cómo restaurar paralelamente las bases de datos usando los binarios de la versión 8.4 para versiones anteriores.

Está muy interesante el mismo, pero me queda una duda que no sé cómo hacerlo:
Al final del mismo, él daba algunas recomendaciones a la hora de enfrentarse a estos procesos de actualización, y dos de éstos puntos son:

1-Los índices de tipo GIN o GIST demasiado largos (usados para full text search y otras cosas) pueden tomar horas en su construcción. Esto puede tomar el 75% del tiempo de la restauración fácilmente, por lo que si estos índices no son requeridos para la producción inmediatamente, omita el proceso de restauración de los mismos usando un archivo personalizado de restauración y constrúyalos después de que la base de datos esté disponible y corriendo.

2-Recuerde que necesita omitir algún módulo del contrib de la actualización, y luego de ello entonces instalarlos en la nueva versión. Los archivos de restauración personalizados pueden ayudarte a hacer esto.

Nunca he sabido cómo hacer estas cosas, o sea: ¿Cómo construir un archivo de restauración personalizable que cuando haga este proceso no me restaure ni los índices GIST/GIN ni los módulos del contrib que tenga instalados en mi servidor de producción?

Saludos

Ing. Marcos Luís Ortíz Valmaseda
PostgreSQL SysDBA
Centro de Tecnologías de Gestión de Datos (DATEC)

Linux User # 418229

TND escribió:
> Saludos, listeros.
> Estaba leyendo un artículo de Josh Berkus en su blog(http://it.toolbox.com/blogs/database-soup/using-84-parallel-restore-with-your-83-or-82-database-31575) sobre cómo restaurar paralelamente las bases de datos usando los binarios de la versión 8.4 para versiones anteriores.
>
> Está muy interesante el mismo, pero me queda una duda que no sé cómo hacerlo:
> Al final del mismo, él daba algunas recomendaciones a la hora de enfrentarse a estos procesos de actualización, y dos de éstos puntos son:
>
> 1-Los índices de tipo GIN o GIST demasiado largos (usados para full text search y otras cosas) pueden tomar horas en su construcción. Esto puede tomar el 75% del tiempo de la restauración fácilmente, por lo que si estos índices no son requeridos para la producción inmediatamente, omita el proceso de restauración de los mismos usando un archivo personalizado de restauración y constrúyalos después de que la base de datos esté disponible y corriendo.
>
> 2-Recuerde que necesita omitir algún módulo del contrib de la actualización, y luego de ello entonces instalarlos en la nueva versión. Los archivos de restauración personalizados pueden ayudarte a hacer esto.
>
> Nunca he sabido cómo hacer estas cosas, o sea: ¿Cómo construir un archivo de restauración personalizable que cuando haga este proceso no me restaure ni los índices GIST/GIN ni los módulos del contrib que tenga instalados en mi servidor de producción?

pg_restore -l
[ ... editas el archivo ...]
pg_restore -L

--
Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257
"Lo esencial es invisible para los ojos" (A. de Saint Exúpery)

Umm, interesante, ¿Y cómo le digo que no me restaure este tipo de índices en específico?
Saludos

Ing. Marcos Luís Ortíz Valmaseda
PostgreSQL SysDBA && Rails Apprentice
Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)
Universidad de las Ciencias Informáticas (http://www.uci.cu)

Linux User # 418229

http://www.postgresql.org
http://www.postgresql-es.org
http://www.rubyonrails.org
http://www.ruby-lang.org/es/
http://www.planetrubyonrails.org/
http://www.planetpostgresql.org

----- Mensaje original -----
De: "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>
Para: "TND" <mlortiz(at)uci(dot)cu>
CC: "pgsql-es-ayuda" <pgsql-es-ayuda(at)postgresql(dot)org>
Enviados: Lunes, 19 de Abril 2010 17:50:56 (GMT-0500) Auto-Detected
Asunto: Re: [pgsql-es-ayuda] Archivos de restauración personalizados para restauración de la db sin los índices GIST/GINy módulos del contrib

TND escribió:
> Saludos, listeros.
> Estaba leyendo un artículo de Josh Berkus en su blog(http://it.toolbox.com/blogs/database-soup/using-84-parallel-restore-with-your-83-or-82-database-31575) sobre cómo restaurar paralelamente las bases de datos usando los binarios de la versión 8.4 para versiones anteriores.
>
> Está muy interesante el mismo, pero me queda una duda que no sé cómo hacerlo:
> Al final del mismo, él daba algunas recomendaciones a la hora de enfrentarse a estos procesos de actualización, y dos de éstos puntos son:
>
> 1-Los índices de tipo GIN o GIST demasiado largos (usados para full text search y otras cosas) pueden tomar horas en su construcción. Esto puede tomar el 75% del tiempo de la restauración fácilmente, por lo que si estos índices no son requeridos para la producción inmediatamente, omita el proceso de restauración de los mismos usando un archivo personalizado de restauración y constrúyalos después de que la base de datos esté disponible y corriendo.
>
> 2-Recuerde que necesita omitir algún módulo del contrib de la actualización, y luego de ello entonces instalarlos en la nueva versión. Los archivos de restauración personalizados pueden ayudarte a hacer esto.
>
> Nunca he sabido cómo hacer estas cosas, o sea: ¿Cómo construir un archivo de restauración personalizable que cuando haga este proceso no me restaure ni los índices GIST/GIN ni los módulos del contrib que tenga instalados en mi servidor de producción?

pg_restore -l
[ ... editas el archivo ...]
pg_restore -L

--
Alvaro Herrera Valdivia, Chile Geotag: -39,815 -73,257
"Lo esencial es invisible para los ojos" (A. de Saint Exúpery)

TND escribió:
> Umm, interesante, ¿Y cómo le digo que no me restaure este tipo de índices en específico?

No tengo idea; me imagino que haces una búsqueda en un editor de texto y
eliminas los que digan "gin" o "gist" ...

--
Alvaro Herrera http://planet.postgresql.org/
"We are who we choose to be", sang the goldfinch
when the sun is high (Sandman)

Acá en el man de pg_restore hay un pequeño ejemplo:

$ pg_restore -l db.dump > db.list

The listing file consists of a header and one line for each item, e.g.:

;
; Archive created at Fri Jul 28 22:28:36 2000
; dbname: mydb
; TOC Entries: 74
; Compression: 0
; Dump Version: 1.4-0
; Format: CUSTOM
;
;
; Selected TOC Entries:
;
2; 145344 TABLE species postgres
3; 145344 ACL species
4; 145359 TABLE nt_header postgres
5; 145359 ACL nt_header
6; 145402 TABLE species_records postgres
7; 145402 ACL species_records
8; 145416 TABLE ss_old postgres
9; 145416 ACL ss_old
10; 145433 TABLE map_resolutions postgres
11; 145433 ACL map_resolutions
12; 145443 TABLE hs_old postgres
13; 145443 ACL hs_old

Semicolons start a comment, and the numbers at the start of lines refer to the internal archive ID assigned to
each item.

Lines in the file can be commented out, deleted, and reordered. For example:

10; 145433 TABLE map_resolutions postgres
;2; 145344 TABLE species postgres
;4; 145359 TABLE nt_header postgres
6; 145402 TABLE species_records postgres
;8; 145416 TABLE ss_old postgres

could be used as input to pg_restore and would only restore items 10 and 6, in that order:

$ pg_restore -L db.list db.dump

Me imagino que sea por aquí.

Saludos y gracias

Ing. Marcos Luís Ortíz Valmaseda
Linux User # 418229 && PostgreSQL DBA
Centro de Tecnologías Gestión de Datos (DATEC)
http://postgresql.uci.cu
http://www.postgresql.org
http://it.toolbox.com/blogs/sql-apprentice