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
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
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
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
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
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
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
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
William Diaz Pabón escribió:
> Jaime estos son los datos que tus pasos:
>
> n_live_tup: 84676478
> n_dead_tup: 514363
>
> reltuples: 84676500
> relpages: 1869958
>
> tamanio_registro: 174.6132663041931033
>
> n_live_tup * tamanio_registro = 14785636402.7151486193341774
>
> count(*): 84126595 -
Jaime estos son los datos que tus pasos:
n_live_tup: 84676478
n_dead_tup: 514363
reltuples: 84676500
relpages: 1869958
tamanio_registro: 174.6132663041931033
n_live_tup * tamanio_registro = 14785636402.7151486193341774
count(*): 84126595 -- este count se demoró 210746 ms
Probe con la tabla qu
Jaime, estoy haciendo lo que me indico Alvaro, y elimine todos los indices
que tenian según tu consulta, un tamaño mayor a 100MB, pero entre esas
estaba la llave primaria de una tabla (también la borre).
Ejecuto tus pasos así con la tabla sin llave primaria? o le tengo que
volver a crear la llave
El día 6 de marzo de 2014, 16:21, Alvaro Herrera
escribió:
> William Diaz Pabón escribió:
>> Gracias Ernesto por contestar.
>>
>> Si, eso lo verifique, acá dejo la salida del comando
>>
>> 5.3M/var/lib/pgsql/data/base/11563
>> 5.3M/var/lib/pgsql/data/base/1
>> 16K /var/lib/pgsql/data/b
2014-03-06 14:34 GMT-05:00 William Diaz Pabón :
>
> Muchas gracias a todos, por sus comentarios.
>
> Ya hice lo que me indicó Jaime y detecte cuales son las tablas e indices que
> ocupan mayor espacio en disco.
>
Si quieres saber si esas tablas e indices están crecidas de tamaño o
el tamaño que t
Muchas gracias a todos, por sus comentarios.
Ya hice lo que me indicó Jaime y detecte cuales son las tablas e indices
que ocupan mayor espacio en disco.
Estoy leyendo lo que me indica Alvaro.
Voy a hacer ese proceso y les estaré contando que pasa.
Gracias.
El 6 de marzo de 2014, 14:22, Jaime
Hola Jaime, gracias por responder.
Acá los datos que me pides:
*du -hs /var/lib/pgsql/data/**
39G /var/lib/pgsql/data/base
1000K /var/lib/pgsql/data/global
784K/var/lib/pgsql/data/pg_clog
4.0K/var/lib/pgsql/data/pg_hba.conf
4.0K/var/lib/pgsql/data/pg_ident.conf
332K/var/lib
2014-03-06 14:16 GMT-05:00 William Diaz Pabón :
>
> 39G /var/lib/pgsql/data/base/24576
Me ganaron ;)
Ya sabemos que la base de datos con oid 24576 es la que mas espacio
usa. Tratemos de ver que tabla o índice usa tanto espacio.
Ejecuta como postgres las siguientes consultas:
select datname f
William Diaz Pabón escribió:
> Gracias Ernesto por contestar.
>
> Si, eso lo verifique, acá dejo la salida del comando
>
> 5.3M/var/lib/pgsql/data/base/11563
> 5.3M/var/lib/pgsql/data/base/1
> 16K /var/lib/pgsql/data/base/pgsql_tmp
> 5.4M/var/lib/pgsql/data/base/11564
> 39G /v
2014-03-06 13:52 GMT-05:00 William Diaz Pabón :
>
> Hola a todos.
>
> Tengo PostgreSQL 8.4 sobre redhat, y ayer la BD pesaba 33GB y hoy amaneció en
> 40GB.
>
> Ejecute el comando:
>
> #vacuumdb -h ip_del_servidor -p puerto -U usuario_postgresql -d base_de_datos
> --full --verbose --analyze
>
> Te
Gracias Ernesto por contestar.
Si, eso lo verifique, acá dejo la salida del comando
5.3M/var/lib/pgsql/data/base/11563
5.3M/var/lib/pgsql/data/base/1
16K /var/lib/pgsql/data/base/pgsql_tmp
5.4M/var/lib/pgsql/data/base/11564
39G /var/lib/pgsql/data/base/24576
39G /var/lib/p
Chequeaste el/los archivo/s de logs?
Para verificar puedes usar du -h o alguna de sus combinaciones, así
sabrás que directorios son los de mayor tamaño y si es correcto o no.
On jue, 2014-03-06 at 13:52 -0500, William Diaz Pabón wrote:
> Hola a todos.
>
>
> Tengo PostgreSQL 8.4 sobre redhat, y a
20 matches
Mail list logo
