Buenos dias Estimados,
Tengo una simple duda con respecto a las extensiones de respaldos que
existen actualmente para el formato custom.. Me encontre que cuando
automatizaba mis respaldos usando la herramienta webmin por defecto se
generan los respaldos con la extension .post lo cual me parecio ex
Hola a todos,
Soy un usuario novato de postgre. Hemos montado una base de datos usando
Postgresql con la extensión PostGIS y hemos probado exitosamente la
conexión desde varios clientes GIS de escritorio (ArcGIS, QGIS, gvSIG,
Kosmo, etc) . Lamentablemente no he encontrado la manera de hacerlo desd
Rusel Fichi escribió:
> Buenos dias Estimados,
>
> Tengo una simple duda con respecto a las extensiones de respaldos que
> existen actualmente para el formato custom.. Me encontre que cuando
> automatizaba mis respaldos usando la herramienta webmin por defecto se
> generan los respaldos con la ext
Bueno les comento como va el tema.
Ya hice lo que me indicó Alvaro y me di cuenta que por el tamaño de la
tabla (que esta en 14 GB con la verificación de espacio que me indicó
Jaime) si le creo los indices que tenia se incrementa enormemente el tamaño
de la base de datos, entonces por ahora los de
Copiado... Sabia que era tontería pero era mejor estar seguro... Gracias
por la aclaratoria..
Saludos!
El 07/03/2014 11:20, "Alvaro Herrera" escribió:
> Rusel Fichi escribió:
> > Buenos dias Estimados,
> >
> > Tengo una simple duda con respecto a las extensiones de respaldos que
> > existen ac
recomiendo intente un vacuum full.
interesante articulo que hace una analogía:
http://rhaas.blogspot.com/2014/03/vacuum-full-doesnt-mean-vacuum-but.html?m=1
El 7 de marzo de 2014, 11:03, William Diaz Pabón escribió:
> Bueno les comento como va el tema.
>
> Ya hice lo que me indicó Alvaro y m
Pero el vacuum full según el articulo
https://wiki.postgresql.org/wiki/VACUUM_FULL no es recomendable para BD 8.4
O entendí mal?
El 7 de marzo de 2014, 11:38, raul andrez gutierrez alejo <
rauland...@gmail.com> escribió:
> recomiendo intente un vacuum full.
>
> interesante articulo que hace una
un vacuum full no debe ser un proceso rutinario, pero en este caso puede
funcionar, tiene el problema que se genera un bloqueo sobre la tabla, ya
que toma una tabla sucia y escribe en un nuevo espacio la tabla completa
con los datos actuales, yo en una db de 66GB con un año de instalada y mas
de 1
2014-03-07 11:03 GMT-05:00 William Diaz Pabón :
>
> Bueno les comento como va el tema.
>
> Ya hice lo que me indicó Alvaro y me di cuenta que por el tamaño de la tabla
> (que esta en 14 GB con la verificación de espacio que me indicó Jaime) si le
> creo los indices que tenia se incrementa enormem
Jaime, por políticas de la empresa no puedo colocar el comando exacto de
los indices, pero puedo decir los siguiente:
En todos utilice: *USING btree*
En unos indices lo hice sobre un campo text: *(campo_text DESC);*
*por ejemplo:*
*CREATE INDEX tabla_campo_ix ON table USING btree (observacio
William
El campo del indice tiene ancho fijo? , si es variable podrías evitar los
blancos con trim.
para reducir el tamaño de la key.
saludos
jmdc
2014-03-07 15:24 GMT-03:00 William Diaz Pabón :
> Jaime, por políticas de la empresa no puedo colocar el comando exacto de
> los indices, pero pu
William Diaz Pabón escribió:
> *por ejemplo:*
>
> *CREATE INDEX tabla_campo_ix ON table USING btree (observacion DESC);*
>
> *otros sin el DESC.*
¿Dos índices sobre el mismo campo, uno con desc y otro sin desc? Uno de
ellos es inútil entonces.
También, si tienes índices multicolumna que te
Sres. les envio este email desde Paraguay. El motivo de este correo es que
estamos necesitando dar unos cursos avanzados de Administración de Postgres
para administradores avanzados
Tendrian algun instructor que nos puedan ofrecer para dictar estos cursos en
Asuncion.
PostgreSQL Adm
13 matches
Mail list logo
