Re: Como eliminar bloqueos

Cordial Saludo Listeros.

Alguien de casualidad ha encontrado algún documento sobre tunning de Postgresql en Windows?
De hecho se encuentran varios sobre el tema pero enfocados a Linux, me imagino que no se encuentra mucha documentación al respecto porque Postgresql es relativamente nuevo en ambiente windows (compilado nativamente).

Si alguien tiene un link, se lo agradecería.

Atentamente,

RAUL DUQUE
Bogotá, Colombia

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.com.mx/

Hola a todos,

Tengo una consulta que esta tomando mucho tiempo en ejecutarse y quisiera saber si alguien me puede dar luces para mejorar esto. La consulta es la siguiente:

explain analyze select distinct docto.barra as barra, docto.copia as copia, to_char(docto.fecha,'dd-mm-yyyy') as fecha,

numero, origen.descripcion as desc_origen, origen2, referencia, nombre, notas

from docto

left outer join origen on (origen = cod_origen)

inner join historia on (docto.barra = historia.barra and docto.copia = historia.copia)

inner join tb_usuario on (historia.comodin = tb_usuario.cod_usuario)

where movimiento = 'A' and actual = 1100

and (historia.barra, historia.copia) in (select barra, copia from historia where movimiento = 'C'

and actual = 1100

and historia.fecha between to_date('04-04-2007','dd-mm-yyyy') and to_date('04-04-2007','dd-mm-yyyy'))

and historia.fecha between to_date('04-04-2007','dd-mm-yyyy') and to_date('04-04-2007','dd-mm-yyyy')

order by barra, copia, nombre

Lo cual me da el siguiente resultado:

Unique (cost=21435.06..21435.09 rows=1 width=221) (actual time=53617.778..53618.047 rows=68 loops=1)

-> Sort (cost=21435.06..21435.06 rows=1 width=221) (actual time=53617.774..53617.848 rows=68 loops=1)

Sort Key: docto.barra, docto.copia, tb_usuario.nombre, to_char((docto.fecha)::timestamp with time zone, 'dd-mm-yyyy'::text), docto.numero, origen.descripcion, docto.origen2, docto.referencia, docto.notas

-> Nested Loop IN Join (cost=17340.22..21435.05 rows=1 width=221) (actual time=2137.102..53617.099 rows=68 loops=1)

Join Filter: (("inner".copia = "outer".copia) AND ("inner".barra = "outer".barra))

-> Nested Loop (cost=17340.22..21429.08 rows=1 width=245) (actual time=2137.004..53571.276 rows=71 loops=1)

Join Filter: (("inner".barra = "outer".barra) AND ("inner".copia = "outer".copia))

-> Nested Loop (cost=0.00..11.66 rows=1 width=43) (actual time=0.109..4.261 rows=71 loops=1)

-> Index Scan using idx_hist_fecha on historia (cost=0.00..5.95 rows=1 width=34) (actual time=0.079..1.998 rows=71 loops=1)

Index Cond: ((fecha >= '2007-04-04'::date) AND (fecha <= '2007-04-04'::date))

Filter: ((movimiento = 'A'::bpchar) AND (actual = 1100::numeric))

-> Index Scan using tb_usuario_pk on tb_usuario (cost=0.00..5.70 rows=1 width=29) (actual time=0.019..0.024 rows=1 loops=71)

Index Cond: ("outer".comodin = tb_usuario.cod_usuario)

-> Merge Right Join (cost=17340.22..19368.35 rows=136605 width=202) (actual time=25.281..557.973 rows=136605 loops=71)

Merge Cond: ("outer".cod_origen = "inner".origen)

-> Index Scan using origen_pk on origen (cost=0.00..6.50 rows=182 width=33) (actual time=0.006..0.482 rows=178 loops=71)

-> Sort (cost=17340.22..17681.73 rows=136605 width=189) (actual time=25.265..174.424 rows=136605 loops=71)

Sort Key: docto.origen

-> Seq Scan on docto (cost=0.00..5688.05 rows=136605 width=189) (actual time=0.008..282.437 rows=136605 loops=1)

-> Index Scan using idx_hist_fecha on historia (cost=0.00..5.95 rows=1 width=24) (actual time=0.046..0.548 rows=36 loops=71)

Index Cond: ((fecha >= '2007-04-04'::date) AND (fecha <= '2007-04-04'::date))

Filter: ((movimiento = 'C'::bpchar) AND (actual = 1100::numeric))

Total runtime: 53646.198 ms

Prácticamente todos los campos involucrados, menos los de naturaleza de caracteres, tienen índices que utilizan btree. Además la tabla historia tiene alrededor de 1,5 millones de registros.

Alguna sugerencia???

Saludos,

Esteban Osorio.

El 4/05/07, Esteban Osorio <eosorio(at)economia(dot)cl> escribió:
>
>
>
>
> Hola a todos,
>
>
>
> Tengo una consulta que esta tomando mucho tiempo en ejecutarse y quisiera
> saber si alguien me puede dar luces para mejorar esto. La consulta es la
> siguiente:
>
[..]
>
>
> Prácticamente todos los campos involucrados, menos los de naturaleza de
> caracteres, tienen índices que utilizan btree. Además la tabla historia
> tiene alrededor de 1,5 millones de registros.
>
>
>
> Alguna sugerencia???

Puedes entregar un script de creación de las tablas ?

>
> Saludos,
>
> Esteban Osorio.

--
_________________________________
Solo soy una mente genial en un cuerpo

On 5/4/07, Esteban Osorio <eosorio(at)economia(dot)cl> wrote:
>
>
>
>
> Hola a todos,
>
>
>
> Tengo una consulta que esta tomando mucho tiempo en ejecutarse y quisiera
> saber si alguien me puede dar luces para mejorar esto. La consulta es la
> siguiente:
>
>
>
> explain analyze select distinct docto.barra as barra, docto.copia as copia,
> to_char(docto.fecha,'dd-mm-yyyy') as fecha,
>
> numero, origen.descripcion as desc_origen, origen2, referencia,
> nombre, notas
>
> from docto
>
> left outer join origen on (origen = cod_origen)
>
> inner join historia on (docto.barra = historia.barra and docto.copia =
> historia.copia)
>
> inner join tb_usuario on (historia.comodin = tb_usuario.cod_usuario)
>
> where movimiento = 'A' and actual = 1100
>
> and (historia.barra, historia.copia) in (select barra, copia from historia
> where movimiento = 'C'
>
> and actual =
> 1100
>
> and
> historia.fecha between to_date('04-04-2007','dd-mm-yyyy')
> and to_date('04-04-2007','dd-mm-yyyy'))
>
> and historia.fecha between
> to_date('04-04-2007','dd-mm-yyyy') and
> to_date('04-04-2007','dd-mm-yyyy')
>
> order by barra, copia, nombre
>
>
>
> Lo cual me da el siguiente resultado:
>
>
>
> Unique (cost=21435.06..21435.09 rows=1 width=221) (actual
> time=53617.778..53618.047 rows=68 loops=1)
>
> -> Sort (cost=21435.06..21435.06 rows=1 width=221) (actual
> time=53617.774..53617.848 rows=68 loops=1)
>
> Sort Key: docto.barra, docto.copia, tb_usuario.nombre,
> to_char((docto.fecha)::timestamp with time zone, 'dd-mm-yyyy'::text),
> docto.numero, origen.descripcion, docto.origen2, docto.referencia,
> docto.notas
>
> -> Nested Loop IN Join (cost=17340.22..21435.05 rows=1 width=221)
> (actual time=2137.102..53617.099 rows=68 loops=1)
>
> Join Filter: (("inner".copia = "outer".copia) AND
> ("inner".barra = "outer".barra))
>
> -> Nested Loop (cost=17340.22..21429.08 rows=1 width=245)
> (actual time=2137.004..53571.276 rows=71 loops=1)
>
> Join Filter: (("inner".barra = "outer".barra) AND
> ("inner".copia = "outer".copia))
>
> -> Nested Loop (cost=0.00..11.66 rows=1 width=43)
> (actual time=0.109..4.261 rows=71 loops=1)
>
> -> Index Scan using idx_hist_fecha on historia
> (cost=0.00..5.95 rows=1 width=34) (actual time=0.079..1.998 rows=71 loops=1)
>
> Index Cond: ((fecha >=
> '2007-04-04'::date) AND (fecha <= '2007-04-04'::date))
>
> Filter: ((movimiento =
> 'A'::bpchar) AND (actual = 1100::numeric))
>
> -> Index Scan using tb_usuario_pk on tb_usuario
> (cost=0.00..5.70 rows=1 width=29) (actual time=0.019..0.024 rows=1 loops=71)
>
> Index Cond:
> ("outer".comodin = tb_usuario.cod_usuario)
>
> -> Merge Right Join (cost=17340.22..19368.35
> rows=136605 width=202) (actual time=25.281..557.973 rows=136605 loops=71)
>
> Merge Cond: ("outer".cod_origen = "inner".origen)
>
> -> Index Scan using origen_pk on origen
> (cost=0.00..6.50 rows=182 width=33) (actual time=0.006..0.482 rows=178
> loops=71)
>
> -> Sort (cost=17340.22..17681.73 rows=136605
> width=189) (actual time=25.265..174.424 rows=136605 loops=71)
>
> Sort Key: docto.origen
>
> -> Seq Scan on docto
> (cost=0.00..5688.05 rows=136605 width=189) (actual time=0.008..282.437
> rows=136605 loops=1)
>
> -> Index Scan using idx_hist_fecha on historia
> (cost=0.00..5.95 rows=1 width=24) (actual time=0.046..0.548 rows=36
> loops=71)
>
> Index Cond: ((fecha >= '2007-04-04'::date) AND (fecha
> <= '2007-04-04'::date))
>
> Filter: ((movimiento = 'C'::bpchar) AND (actual =
> 1100::numeric))
>
> Total runtime: 53646.198 ms
>
>
>
> Prácticamente todos los campos involucrados, menos los de naturaleza de
> caracteres, tienen índices que utilizan btree. Además la tabla historia
> tiene alrededor de 1,5 millones de registros.
>
>
>
> Alguna sugerencia???
>
>

de entrada 2

1 vacuum
2 indices

--
Leonel

Utiliza el cast

::bpchar
::bigint
en tu clausula where

movimiento = 'A'::bpchar and actual = 1100::bigint

claro acompañado de índices
----- Original Message -----
From: "usuario anonimo" <opinante(dot)anonimo(at)gmail(dot)com>
To: "Esteban Osorio" <eosorio(at)economia(dot)cl>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Friday, May 04, 2007 7:39 PM
Subject: Re: [pgsql-es-ayuda] Mejorar performance de un query.

El 4/05/07, Esteban Osorio <eosorio(at)economia(dot)cl> escribió:
>
>
>
>
> Hola a todos,
>
>
>
> Tengo una consulta que esta tomando mucho tiempo en ejecutarse y quisiera
> saber si alguien me puede dar luces para mejorar esto. La consulta es la
> siguiente:
>
[..]
>
>
> Prácticamente todos los campos involucrados, menos los de naturaleza de
> caracteres, tienen índices que utilizan btree. Además la tabla historia
> tiene alrededor de 1,5 millones de registros.
>
>
>
> Alguna sugerencia???

Puedes entregar un script de creación de las tablas ?

>
> Saludos,
>
> Esteban Osorio.

--
_________________________________
Solo soy una mente genial en un cuerpo

---------------------------(fin del mensaje)---------------------------
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

--
Estoy usando la versión gratuita de SPAMfighter para usuarios privados.
Ha eliminado 2511 correos spam hasta la fecha.
Los usuarios de pago no tienen este mensaje en sus correos.
Obtenga SPAMfighter gratis aquí: http://www.spamfighter.com/les

Aquí va un script de las tablas y sus índices...

CREATE TABLE docto
(
barra numeric(9) NOT NULL,
tipo numeric(9),
numero character(9),
fecha date,
origen numeric(9),
accion numeric(9),
cooperativa numeric(9),
referencia text,
fechcreacion date,
grupo numeric(3),
origen2 character varying(50),
notas text,
copia numeric(3) NOT NULL DEFAULT 1,
sin_uso numeric(9),
asoc_gremial character(10),
antecedente1 numeric(9),
antecedente2 numeric(9),
antecedente3 numeric(9),
antecedente4 numeric(9),
CONSTRAINT pk_docto PRIMARY KEY (barra, copia),
CONSTRAINT fk_docto_reference_accion FOREIGN KEY (accion)
REFERENCES accion (cod_accion) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fk_docto_reference_asoc_gre FOREIGN KEY (sin_uso)
REFERENCES asoc_gremial (cod_gremial) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fk_docto_reference_cooperat FOREIGN KEY (cooperativa)
REFERENCES cooperativa (num_rol) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fk_docto_reference_origen FOREIGN KEY (origen)
REFERENCES origen (cod_origen) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fk_docto_reference_tipo FOREIGN KEY (tipo)
REFERENCES tipo (cod_tipo) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
)

-- Index: docto_pk
CREATE UNIQUE INDEX docto_pk
ON docto
USING btree
(barra, copia);

-- Index: idx_docto_barra
CREATE INDEX idx_docto_barra
ON docto
USING btree
(barra);

-- Index: idx_docto_copia
CREATE INDEX idx_docto_copia
ON docto
USING btree
(copia);

-- Index: idx_docto_origen
CREATE INDEX idx_docto_origen
ON docto
USING btree
(origen);

-- Index: idx_docto_tipo
CREATE INDEX idx_docto_tipo
ON docto
USING btree
(tipo);

CREATE TABLE historia
(
barra numeric(9),
cod_usuario numeric(9),
cod_archivador numeric(9),
correlativo serial NOT NULL,
movimiento character(1),
fecha date,
computador character varying(15),
actual numeric(9),
comodin numeric(9),
copia numeric(3) DEFAULT 1,
hora time without time zone,
CONSTRAINT pk_historia PRIMARY KEY (correlativo),
CONSTRAINT fk_historia_actual_ref_usuar FOREIGN KEY (actual)
REFERENCES tb_usuario (cod_usuario) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fk_historia_comodin_ref_usuar FOREIGN KEY (comodin)
REFERENCES tb_usuario (cod_usuario) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fk_historia_reference_carpetas FOREIGN KEY (cod_archivador)
REFERENCES carpetas_archivo (cod_archivador) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fk_historia_reference_docto FOREIGN KEY (barra, copia)
REFERENCES docto (barra, copia) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT,
CONSTRAINT fk_historia_usuario_ref_usuar FOREIGN KEY (cod_usuario)
REFERENCES tb_usuario (cod_usuario) MATCH SIMPLE
ON UPDATE RESTRICT ON DELETE RESTRICT
)

-- Index: historia_pk
CREATE UNIQUE INDEX historia_pk
ON historia
USING btree
(correlativo);

-- Index: idx_hist_barra_copia_comodin_actual
CREATE INDEX idx_hist_barra_copia_comodin_actual
ON historia
USING btree
(barra, copia, comodin, actual, fecha);

-- Index: idx_hist_fecha
CREATE INDEX idx_hist_fecha
ON historia
USING btree
(fecha);

-- Index: idx_historia_barra
CREATE INDEX idx_historia_barra
ON historia
USING btree
(barra);

-- Index: idx_historia_copia
CREATE INDEX idx_historia_copia
ON historia
USING btree
(copia);

-- Index: reference_10_fk
CREATE INDEX reference_10_fk
ON historia
USING btree
(cod_usuario);

-- Index: reference_19_fk
CREATE INDEX reference_19_fk
ON historia
USING btree
(cod_archivador);

-- Index: reference_20_fk
CREATE INDEX reference_20_fk
ON historia
USING btree
(comodin);

-- Index: reference_21_fk
CREATE INDEX reference_21_fk
ON historia
USING btree
(actual);

-- Index: reference_9_fk
CREATE INDEX reference_9_fk
ON historia
USING btree
(barra, copia);

CREATE TABLE tb_usuario
(
cod_usuario numeric(9) NOT NULL,
nombre character varying(50),
"password" character(8),
tipo character(1),
estado character(1),
"login" character(12),
CONSTRAINT pk_tb_usuario PRIMARY KEY (cod_usuario)
)

-- Index: tb_usuario_pk
CREATE UNIQUE INDEX tb_usuario_pk
ON tb_usuario
USING btree
(cod_usuario);

Saludos,
Esteban Osorio.

-----Mensaje original-----
De: usuario anonimo [mailto:opinante(dot)anonimo(at)gmail(dot)com]
Enviado el: Viernes, 04 de Mayo de 2007 20:40
Para: Esteban Osorio
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] Mejorar performance de un query.

El 4/05/07, Esteban Osorio <eosorio(at)economia(dot)cl> escribió:
>
>
>
>
> Hola a todos,
>
>
>
> Tengo una consulta que esta tomando mucho tiempo en ejecutarse y quisiera
> saber si alguien me puede dar luces para mejorar esto. La consulta es la
> siguiente:
>
[..]
>
>
> Prácticamente todos los campos involucrados, menos los de naturaleza de
> caracteres, tienen índices que utilizan btree. Además la tabla historia
> tiene alrededor de 1,5 millones de registros.
>
>
>
> Alguna sugerencia???

Puedes entregar un script de creación de las tablas ?

>
> Saludos,
>
> Esteban Osorio.

--
_________________________________
Solo soy una mente genial en un cuerpo

Realizo un vacuum diario por las noches utilizando la siguiente instrucción:

vacuumdb -U postgres -v -z -d base_de_datos

He creado tantos índices como he visto que sean necesarios.

Saludos,
Esteban.

-----Mensaje original-----
De: Leonel [mailto:lnunez(at)gmail(dot)com]
Enviado el: Viernes, 04 de Mayo de 2007 21:47
Para: Esteban Osorio
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] Mejorar performance de un query.

On 5/4/07, Esteban Osorio <eosorio(at)economia(dot)cl> wrote:
>
>
>
>
> Hola a todos,
>
>
>
> Tengo una consulta que esta tomando mucho tiempo en ejecutarse y quisiera
> saber si alguien me puede dar luces para mejorar esto. La consulta es la
> siguiente:
>
>
>
> explain analyze select distinct docto.barra as barra, docto.copia as copia,
> to_char(docto.fecha,'dd-mm-yyyy') as fecha,
>
> numero, origen.descripcion as desc_origen, origen2, referencia,
> nombre, notas
>
> from docto
>
> left outer join origen on (origen = cod_origen)
>
> inner join historia on (docto.barra = historia.barra and docto.copia =
> historia.copia)
>
> inner join tb_usuario on (historia.comodin = tb_usuario.cod_usuario)
>
> where movimiento = 'A' and actual = 1100
>
> and (historia.barra, historia.copia) in (select barra, copia from historia
> where movimiento = 'C'
>
> and actual =
> 1100
>
> and
> historia.fecha between to_date('04-04-2007','dd-mm-yyyy')
> and to_date('04-04-2007','dd-mm-yyyy'))
>
> and historia.fecha between
> to_date('04-04-2007','dd-mm-yyyy') and
> to_date('04-04-2007','dd-mm-yyyy')
>
> order by barra, copia, nombre
>
>
>
> Lo cual me da el siguiente resultado:
>
>
>
> Unique (cost=21435.06..21435.09 rows=1 width=221) (actual
> time=53617.778..53618.047 rows=68 loops=1)
>
> -> Sort (cost=21435.06..21435.06 rows=1 width=221) (actual
> time=53617.774..53617.848 rows=68 loops=1)
>
> Sort Key: docto.barra, docto.copia, tb_usuario.nombre,
> to_char((docto.fecha)::timestamp with time zone, 'dd-mm-yyyy'::text),
> docto.numero, origen.descripcion, docto.origen2, docto.referencia,
> docto.notas
>
> -> Nested Loop IN Join (cost=17340.22..21435.05 rows=1 width=221)
> (actual time=2137.102..53617.099 rows=68 loops=1)
>
> Join Filter: (("inner".copia = "outer".copia) AND
> ("inner".barra = "outer".barra))
>
> -> Nested Loop (cost=17340.22..21429.08 rows=1 width=245)
> (actual time=2137.004..53571.276 rows=71 loops=1)
>
> Join Filter: (("inner".barra = "outer".barra) AND
> ("inner".copia = "outer".copia))
>
> -> Nested Loop (cost=0.00..11.66 rows=1 width=43)
> (actual time=0.109..4.261 rows=71 loops=1)
>
> -> Index Scan using idx_hist_fecha on historia
> (cost=0.00..5.95 rows=1 width=34) (actual time=0.079..1.998 rows=71 loops=1)
>
> Index Cond: ((fecha >=
> '2007-04-04'::date) AND (fecha <= '2007-04-04'::date))
>
> Filter: ((movimiento =
> 'A'::bpchar) AND (actual = 1100::numeric))
>
> -> Index Scan using tb_usuario_pk on tb_usuario
> (cost=0.00..5.70 rows=1 width=29) (actual time=0.019..0.024 rows=1 loops=71)
>
> Index Cond:
> ("outer".comodin = tb_usuario.cod_usuario)
>
> -> Merge Right Join (cost=17340.22..19368.35
> rows=136605 width=202) (actual time=25.281..557.973 rows=136605 loops=71)
>
> Merge Cond: ("outer".cod_origen = "inner".origen)
>
> -> Index Scan using origen_pk on origen
> (cost=0.00..6.50 rows=182 width=33) (actual time=0.006..0.482 rows=178
> loops=71)
>
> -> Sort (cost=17340.22..17681.73 rows=136605
> width=189) (actual time=25.265..174.424 rows=136605 loops=71)
>
> Sort Key: docto.origen
>
> -> Seq Scan on docto
> (cost=0.00..5688.05 rows=136605 width=189) (actual time=0.008..282.437
> rows=136605 loops=1)
>
> -> Index Scan using idx_hist_fecha on historia
> (cost=0.00..5.95 rows=1 width=24) (actual time=0.046..0.548 rows=36
> loops=71)
>
> Index Cond: ((fecha >= '2007-04-04'::date) AND (fecha
> <= '2007-04-04'::date))
>
> Filter: ((movimiento = 'C'::bpchar) AND (actual =
> 1100::numeric))
>
> Total runtime: 53646.198 ms
>
>
>
> Prácticamente todos los campos involucrados, menos los de naturaleza de
> caracteres, tienen índices que utilizan btree. Además la tabla historia
> tiene alrededor de 1,5 millones de registros.
>
>
>
> Alguna sugerencia???
>
>

de entrada 2

1 vacuum
2 indices

--
Leonel

Buenas, estoy empezando con postgreSql y voy a montar una base de datos en la
que me exigen una alta disponibilidad, he estado leyendo la documentación y
me parece que la mejor opción sería utilizar DRBD para mantener un servidor
copia de reserva para el caso de fallo en el servidor maestro, pero mi duda
es porque esto es mejor que montar un RAID en el Sistema operativo?
Cual seria la mejor opción para una base de datos cuya mayor carga de trabajo
serán consultas para mostrar informes?

Gracias por anticipado.
Un saludo

Esteban Osorio escribió:
> Hola a todos,

Que version estas usando?

Creo que aca el principal problema es el outer join, que esta bloqueando
la optimizacion del join entre historia y documento. En una version
reciente (creo que 8.2) se introdujo la posibilidad de reordenar outer
joins, lo cual es muy beneficioso en casos como este.

Otra cosa que me llama la atencion es que la estimacion de registros de
historia se equivoca en casi dos ordenes de magnitud; puede ser que eso
este haciendo que escoja mal el resto del plan.

Me refiero a este nodo de aca:

-> Index Scan using idx_hist_fecha on historia (cost=0.00..5.95 rows=1 width=34) (actual time=0.079..1.998 rows=71 loops=1)
Index Cond: ((fecha >= '2007-04-04'::date) AND (fecha <= '2007-04-04'::date))
Filter: ((movimiento = 'A'::bpchar) AND (actual = 1100::numeric))

(espera 1 tupla, recibe 71) que se repite en este otro nodo:

-> Index Scan using idx_hist_fecha on historia (cost=0.00..5.95 rows=1 width=24) (actual time=0.046..0.548 rows=36 loops=71)
Index Cond: ((fecha >= '2007-04-04'::date) AND (fecha <= '2007-04-04'::date))
Filter: ((movimiento = 'C'::bpchar) AND (actual = 1100::numeric))

(espera 1 tupla, recibe 36)

Quizas lo que podrias hacer es capturar mas datos estadisticos para
historia, a ver si mejora la estimacion. Si mal no recuerdo la sintaxis
es algo asi:

alter table historia alter column fecha set statistics 100;
analyze;

Prueba tambien cambiando la condicion
fecha BETWEEN 'una fecha' AND 'la misma fecha'

en
fecha = 'la fecha'

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On 5/8/07, jlcambero <jlcambero(at)emergya(dot)es> wrote:
> Buenas, estoy empezando con postgreSql y voy a montar una base de datos en la
> que me exigen una alta disponibilidad, he estado leyendo la documentación y
> me parece que la mejor opción sería utilizar DRBD para mantener un servidor
> copia de reserva para el caso de fallo en el servidor maestro, pero mi duda
> es porque esto es mejor que montar un RAID en el Sistema operativo?
> Cual seria la mejor opción para una base de datos cuya mayor carga de trabajo
> serán consultas para mostrar informes?
>
> Gracias por anticipado.
> Un saludo
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
>

pon slony para la replica

la mayoria de las consultas se vayan al server replicado
y deja las actualizaciones solo en el master

asi podras tener N servidores

yo pondria

1 master donde se harian todos los updates
1 o mas esclavos solo para las consultas
1 o mas esclavos COMO respaldo

claro dependiendo de $$$$

--
Leonel

Utilizo la 8.1.4

Acabo de realizar la prueba recreando la base de datos en un Pg ver. 8.2 y los resultados hablan por si solos (y eso que lo instalé en una máquina Windows sin ninguna configuración especial):

QUERY PLAN

----------------------------------------------------------------------------
----------------------------------------------------------------------------
Unique (cost=37.72..37.75 rows=1 width=224) (actual time=35.585..35.966 rows=6
8 loops=1)
-> Sort (cost=37.72..37.73 rows=1 width=224) (actual time=35.578..35.688 ro
ws=68 loops=1)
Sort Key: docto.barra, docto.copia, tb_usuario.nombre, to_char((docto.f
echa)::timestamp with time zone, 'dd-mm-yyyy'::text), docto.numero, origen.descr
ipcion, docto.origen2, docto.referencia, docto.notas
-> Nested Loop Left Join (cost=0.01..37.71 rows=1 width=224) (actual
time=0.261..35.211 rows=68 loops=1)
-> Nested Loop (cost=0.01..33.43 rows=1 width=211) (actual time
=0.218..33.859 rows=68 loops=1)
-> Nested Loop IN Join (cost=0.01..25.15 rows=1 width=202
) (actual time=0.194..32.673 rows=68 loops=1)
Join Filter: ((public.historia.copia = docto.copia) A
ND (public.historia.barra = docto.barra))
-> Nested Loop (cost=0.01..16.72 rows=1 width=226)
(actual time=0.137..2.533 rows=71 loops=1)
Join Filter: (docto.copia = public.historia.cop
ia)
-> Index Scan using idx_hist_fecha on historia
(cost=0.01..8.41 rows=1 width=34) (actual time=0.095..0.893 rows=71 loops=1)
Index Cond: ((fecha >= to_date('04-04-200
7'::text, 'dd-mm-yyyy'::text)) AND (fecha <= to_date('04-04-2007'::text, 'dd-mm-
yyyy'::text)))
Filter: ((movimiento = 'A'::bpchar) AND (
actual = 1100::numeric))
-> Index Scan using idx_docto_barra on docto
(cost=0.00..8.29 rows=1 width=192) (actual time=0.009..0.011 rows=1 loops=71)
Index Cond: (docto.barra = public.histori
a.barra)
-> Index Scan using idx_hist_fecha on historia (cos
t=0.01..8.41 rows=1 width=24) (actual time=0.039..0.345 rows=36 loops=71)
Index Cond: ((fecha >= to_date('04-04-2007'::te
xt, 'dd-mm-yyyy'::text)) AND (fecha <= to_date('04-04-2007'::text, 'dd-mm-yyyy':
:text)))
Filter: ((movimiento = 'C'::bpchar) AND (actual
= 1100::numeric))
-> Index Scan using tb_usuario_pk on tb_usuario (cost=0.0
0..8.27 rows=1 width=29) (actual time=0.005..0.007 rows=1 loops=68)
Index Cond: (public.historia.comodin = tb_usuario.cod
_usuario)
-> Index Scan using origen_pk on origen (cost=0.00..4.27 rows=1
width=33) (actual time=0.004..0.006 rows=1 loops=68)
Index Cond: (docto.origen = origen.cod_origen)
Total runtime: 36.362 ms
(22 filas)

Parece que voy a tener que actualizar mi versión, cosa que no será fácil debido a la cantidad de bases de datos e información ya registrada en ellas.

Saludos y gracias por su ayuda,
Esteban.

-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre(at)commandprompt(dot)com]
Enviado el: Martes, 08 de Mayo de 2007 9:07
Para: Esteban Osorio
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] Mejorar performance de un query.

Esteban Osorio escribió:
> Hola a todos,

Que version estas usando?

Creo que aca el principal problema es el outer join, que esta bloqueando
la optimizacion del join entre historia y documento. En una version
reciente (creo que 8.2) se introdujo la posibilidad de reordenar outer
joins, lo cual es muy beneficioso en casos como este.

Otra cosa que me llama la atencion es que la estimacion de registros de
historia se equivoca en casi dos ordenes de magnitud; puede ser que eso
este haciendo que escoja mal el resto del plan.

Me refiero a este nodo de aca:

-> Index Scan using idx_hist_fecha on historia (cost=0.00..5.95 rows=1 width=34) (actual time=0.079..1.998 rows=71 loops=1)
Index Cond: ((fecha >= '2007-04-04'::date) AND (fecha <= '2007-04-04'::date))
Filter: ((movimiento = 'A'::bpchar) AND (actual = 1100::numeric))

(espera 1 tupla, recibe 71) que se repite en este otro nodo:

-> Index Scan using idx_hist_fecha on historia (cost=0.00..5.95 rows=1 width=24) (actual time=0.046..0.548 rows=36 loops=71)
Index Cond: ((fecha >= '2007-04-04'::date) AND (fecha <= '2007-04-04'::date))
Filter: ((movimiento = 'C'::bpchar) AND (actual = 1100::numeric))

(espera 1 tupla, recibe 36)

Quizas lo que podrias hacer es capturar mas datos estadisticos para
historia, a ver si mejora la estimacion. Si mal no recuerdo la sintaxis
es algo asi:

alter table historia alter column fecha set statistics 100;
analyze;

Prueba tambien cambiando la condicion
fecha BETWEEN 'una fecha' AND 'la misma fecha'

en
fecha = 'la fecha'

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Buenas, he pasado de Oracle a Postgre y estoy un poco perdido.
Mi duda es si no puedo ejecutar codigo pgsql dentro de un declare begin end;
sin tener que crear una funcion?

Por ejemplo en oracle al preparar scripts hacia esto:

DECLARE
variables......
BEGIN
BEGIN
instrucciones....
EXCEPTION WHEN OTHERS THEN
guardar informacion sobre el error
MOSTRAR UN RESUMEN DEL SCRIPT
END;

y esto lo podia ejecutar como una sql más.

no puedo hacer esto en PostgreSql????
Si no puedo hacerlo, que tendria que crear funciones e irlas ejecutando??

Gracias de antemano, un saludo

jlcambero escribió:
>
> Buenas, he pasado de Oracle a Postgre y estoy un poco perdido.
> Mi duda es si no puedo ejecutar codigo pgsql dentro de un declare begin end;
> sin tener que crear una funcion?

No.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Pregunta a una pregunta:

Se puede ejecutar codigto plsql en Oracle sin llamar a una funcion?

g.-

On 5/9/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> jlcambero escribió:
> >
> > Buenas, he pasado de Oracle a Postgre y estoy un poco perdido.
> > Mi duda es si no puedo ejecutar codigo pgsql dentro de un declare begin end;
> > sin tener que crear una funcion?
>
> No.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 8: explain analyze es tu amigo
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido(dot)barosio(at)globant(dot)com

En Oracle Si.

declare
-- Aqui si necesita variables o cursores
begin
-- aqui plsql
end;

o simplemente

begin
-- aqui plsql
end;

Guido Barosio <gbarosio(at)gmail(dot)com> escribió: Pregunta a una pregunta:

Se puede ejecutar codigto plsql en Oracle sin llamar a una funcion?

g.-

On 5/9/07, Alvaro Herrera wrote:
> jlcambero escribió:
> >
> > Buenas, he pasado de Oracle a Postgre y estoy un poco perdido.
> > Mi duda es si no puedo ejecutar codigo pgsql dentro de un declare begin end;
> > sin tener que crear una funcion?
>
> No.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 8: explain analyze es tu amigo
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido(dot)barosio(at)globant(dot)com

---------------------------(fin del mensaje)---------------------------
TIP 10: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

William Enrique Parra Alba
Ingeniero De Sistemas
Universidad Pedagógica y Tecnológica de Colombia
/\ /\
/ //\\ \
\ \\// /
/ / \ \
\/ \/
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

jlcambero escribió:
> Buenas, estoy empezando con postgreSql y voy a montar una base de datos en la
> que me exigen una alta disponibilidad, he estado leyendo la documentación y
> me parece que la mejor opción sería utilizar DRBD para mantener un servidor
> copia de reserva para el caso de fallo en el servidor maestro, pero mi duda
> es porque esto es mejor que montar un RAID en el Sistema operativo?
> Cual seria la mejor opción para una base de datos cuya mayor carga de trabajo
> serán consultas para mostrar informes?

Dale una leida por aca
http://www.postgresql.org/docs/8.2/static/high-availability.html

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

El 8/05/07, jlcambero <jlcambero(at)emergya(dot)es> escribió:
> Buenas, estoy empezando con postgreSql y voy a montar una base de datos en la
> que me exigen una alta disponibilidad, he estado leyendo la documentación y
> me parece que la mejor opción sería utilizar DRBD para mantener un servidor
> copia de reserva para el caso de fallo en el servidor maestro, pero mi duda
> es porque esto es mejor que montar un RAID en el Sistema operativo?
> Cual seria la mejor opción para una base de datos cuya mayor carga de trabajo
> serán consultas para mostrar informes?

Prueba con Sequoia:
http://sequoia.continuent.org/Overview
Si la mayor carga es lectura de datos debieras implementar un RAIDb-1. Mira:
http://sequoia.continuent.org/doc/infocenter/topic/org.continuent.sequoia.doc/html/Full_replication_RAIDb-1.html

Saludos,
Edgard Pineda.

Buenas lista, quiero guardar un "fichero de log" con un resumen y datos de
interés sobre la ejecución de una función. Como se hace?

Gracias, un saludo

jlcambero escribió:
> Buenas lista, quiero guardar un "fichero de log" con un resumen y datos de
> interés sobre la ejecución de una función. Como se hace?

En psql puedes usar
\o <fichero>
y guardara la salida de las consultas en ese fichero. Luego, \o vuelve
al modo normal.

Para salida de depuracion en una funcion PL/pgSQL puedes usar RAISE
NOTICE.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Buenas lista, se me han quedado colgadas unas select y ahora tengo bloqueadas
unas tablas y no se como eliminar los bloqueos.
Alguien puede ayudarme?

Los tipos de bloqueos que tengo son AccessShareLock, rowExclusiveLock y
ExclusiveLock.

Gracias, un saludo

Se me ha olvidado comentar que con el pgAdmin ya he intentado finalizar los
bloqueos y la sesion que los ha provocado (que se ha quedado abierta) y no ha
funcionado.

Gracias

El Martes, 22 de Mayo de 2007 12:06, jlcambero escribió:
> Buenas lista, se me han quedado colgadas unas select y ahora tengo
> bloqueadas unas tablas y no se como eliminar los bloqueos.
> Alguien puede ayudarme?
>
> Los tipos de bloqueos que tengo son AccessShareLock, rowExclusiveLock y
> ExclusiveLock.
>
> Gracias, un saludo
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 5: ¿Has leído nuestro extenso FAQ?
>
> http://www.postgresql.org/files/documentation/faqs/FAQ.html

--
Jose Luis Cambero Contador
Emergya, Consultoría e Ingeniería
Avda. de la Innovación, 3. Edif. Hércules.
E41020 - Sevilla
Tel. +34 954 51 75 77
Fax. +34 954 51 64 73
http://www.emergya.info

Hola José Luis...

On Tue, 22 May 2007 12:28:16 +0200, jlcambero wrote
> Se me ha olvidado comentar que con el pgAdmin ya he intentado
> finalizar los bloqueos y la sesion que los ha provocado (que se ha
> quedado abierta) y no ha funcionado.
>
> Gracias

Ya me tirarán las orejas si te estoy dando un mal consejo, pero yo lo hice y
no me dió problemas. Podés hacer dentro de psql:

SELECT procpid FROM pg_stat_activity WHERE datname = 'tuBaseDatos';

Y después le hacés un simple "kill" al procpid. Saludos...

p/d: estoy suponiendo que estás trabajando bajo Linux. Supongo que no debe ser
muy distinto en Windows.

-
-------------------------------------------
Sebastián Villalba
sebastian(at)fcm(dot)unc(dot)edu(dot)ar
-------------------------------------------

No se me había ocurrido, me lo guardo para otra, porque ahora ya lo habia
solucionado.

Gracias

El Martes, 22 de Mayo de 2007 13:56, Sebastián Villalba escribió:
> Hola José Luis...
>
> On Tue, 22 May 2007 12:28:16 +0200, jlcambero wrote
>
> > Se me ha olvidado comentar que con el pgAdmin ya he intentado
> > finalizar los bloqueos y la sesion que los ha provocado (que se ha
> > quedado abierta) y no ha funcionado.
> >
> > Gracias
>
> Ya me tirarán las orejas si te estoy dando un mal consejo, pero yo lo hice
> y no me dió problemas. Podés hacer dentro de psql:
>
> SELECT procpid FROM pg_stat_activity WHERE datname = 'tuBaseDatos';
>
> Y después le hacés un simple "kill" al procpid. Saludos...
>
> p/d: estoy suponiendo que estás trabajando bajo Linux. Supongo que no debe
> ser muy distinto en Windows.
>
> -
> -------------------------------------------
> Sebastián Villalba
> sebastian(at)fcm(dot)unc(dot)edu(dot)ar
> -------------------------------------------
>
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
>
> http://archives.postgresql.org/pgsql-es-ayuda

--
Jose Luis Cambero Contador
Emergya, Consultoría e Ingeniería
Avda. de la Innovación, 3. Edif. Hércules.
E41020 - Sevilla
Tel. +34 954 51 75 77
Fax. +34 954 51 64 73
http://www.emergya.info

On 5/22/07, Sebastián Villalba <sebastian(at)fcm(dot)unc(dot)edu(dot)ar> wrote:
> Hola José Luis...
>
> On Tue, 22 May 2007 12:28:16 +0200, jlcambero wrote
> > Se me ha olvidado comentar que con el pgAdmin ya he intentado
> > finalizar los bloqueos y la sesion que los ha provocado (que se ha
> > quedado abierta) y no ha funcionado.
> >
> > Gracias
>
> Ya me tirarán las orejas si te estoy dando un mal consejo, pero yo lo hice y
> no me dió problemas. Podés hacer dentro de psql:
>
> SELECT procpid FROM pg_stat_activity WHERE datname = 'tuBaseDatos';
>
ok, hasta aqui... pero no hagas kill mejor usa pg_cancel_backend(pid int)

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

Hola Jaime...

On Tue, 22 May 2007 22:47:05 -0500, Jaime Casanova wrote
> > SELECT procpid FROM pg_stat_activity WHERE datname = 'tuBaseDatos';
> >
> ok, hasta aqui... pero no hagas kill mejor usa pg_cancel_backend(pid
> int)

Seguramente es mejor utilizar éste comando provisto por PostgreSQL. No
obstante me surgió una duda. Viendo la documentación(1) ví que
"pg_cancel_backend" envía una señal SIGINT, mientras que yo sugerí un "simple
kill" con lo que cual se le enviaría un SIGTERM al proceso. Deduzco según la
diferencia que encontré en internet(2) entre el SIGINT y SIGTERM que sería
mejor para el proceso recibir un SIGTERM, ya que éste último le dá la
posibilidad de que finalice al proceso en lugar de interrumpirlo.

Perdón porque quizás ésto ya se torne "Semi-OT" ¿no?. Un gran saludo para todos...

(1)http://www.postgresql.org/docs/8.2/static/functions-admin.html
(2)http://www.cristalab.com/foros/viewtopic.php?p=55160 y
http://www.osmosislatina.com/linux/comandos.jsp

-
-------------------------------------------
Sebastián Villalba
sebastian(at)fcm(dot)unc(dot)edu(dot)ar
-------------------------------------------

Sebastián Villalba escribió:
> Hola Jaime...
>
> On Tue, 22 May 2007 22:47:05 -0500, Jaime Casanova wrote
> > > SELECT procpid FROM pg_stat_activity WHERE datname = 'tuBaseDatos';
> > >
> > ok, hasta aqui... pero no hagas kill mejor usa pg_cancel_backend(pid
> > int)
>
> Seguramente es mejor utilizar éste comando provisto por PostgreSQL. No
> obstante me surgió una duda. Viendo la documentación(1) ví que
> "pg_cancel_backend" envía una señal SIGINT, mientras que yo sugerí un "simple
> kill" con lo que cual se le enviaría un SIGTERM al proceso. Deduzco según la
> diferencia que encontré en internet(2) entre el SIGINT y SIGTERM que sería
> mejor para el proceso recibir un SIGTERM, ya que éste último le dá la
> posibilidad de que finalice al proceso en lugar de interrumpirlo.

Eso podria ser cierto con el manejo de señales en general(*), pero en
Postgres las señales son manejadas de formas lo más inteligentes
posible. SIGINT se usa para cancelar una consulta que está en
ejecución, y es totalmente "seguro". En cambio SIGTERM se diseñó
inicialmente como una señal que se le manda a todos los procesos cuando
se está bajando el servicio, de manera que la intención era que ningún
proceso iba a seguir corriendo, todos iban a salir.

Por lo tanto hay un cierto recelo de parte de Tom Lane de que puede
ocurrir que si un backend recibe SIGTERM en un momento inapropiado,
puede salir sin liberar todos los recursos (se liberarían sin problemas
si terminaran todos los backends, pero como el resto continúa
funcionando no hay modo de asegurar que esto suceda). De hecho hace
poco se corrigió un bug de este tipo.

(*) Sin embargo yo creo que estás equivocado, puesto que SIGINT
generalmente es capturado por la aplicacion de forma robusta igual que
SIGTERM (o debería serlo; y cuando no lo es, es un bug). La señal que
deja al proceso sin la posibilidad de salir limpiamente y cerrar los
recursos es SIGKILL. Ésta es la señal que no debe ser usada, a menos
que se trate de un caso muy muy extremo.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Buenas lista, estoy diseñando un modelo bastante grande para postgresql y me
gustaria saber si existe algun programa para comprobar si esta normalizado.

Gracias, un saludo

On 5/25/07, jlcambero <jlcambero(at)emergya(dot)es> wrote:
> Buenas lista, estoy diseñando un modelo bastante grande para postgresql y me
> gustaria saber si existe algun programa para comprobar si esta normalizado.
>

esta es una de las peticiones mas raras que he visto... no, la
computadora no va a pensar por ti... puede hacer las cosas mas rapido
nada mas...

alguien dijo "la computadora es un tonto super rapido"

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

--- Jaime Casanova <systemguards(at)gmail(dot)com> escribió:

> On 5/25/07, jlcambero <jlcambero(at)emergya(dot)es> wrote:
> > Buenas lista, estoy diseñando un modelo bastante
> grande para postgresql y me
> > gustaria saber si existe algun programa para
> comprobar si esta normalizado.
> >
>
> esta es una de las peticiones mas raras que he
> visto... no, la
> computadora no va a pensar por ti... puede hacer las
> cosas mas rapido
> nada mas...
>
> alguien dijo "la computadora es un tonto super
> rapido"
>
> --
> Atentamente,
> Jaime Casanova
>
> "Programming today is a race between software
> engineers striving to
> build bigger and better idiot-proof programs and the
> universe trying
> to produce bigger and better idiots.
> So far, the universe is winning."
> Richard Cook
>
> ---------------------------(fin del
> mensaje)---------------------------
> TIP 2: puedes desuscribirte de todas las listas
> simultáneamente
> (envíe "unregister TuDirecciónDeCorreo" a
> majordomo(at)postgresql(dot)org)
>
Lo maximo que he visto al respecto es la posibilidad
de que una herramienta te sugiera dividir una tabla,
para evitar redundancias, por ejemplo.

id_articulo
descripcion
modelo
marca
precio

La herramienta te sugeriria que hagas tres tablas

Tabla origen
id_articulo
descripcion
id_marca
id_modelo
precio

Sugeridas
Id_marca, marca
id_modelo,modelo

Y no puede llegar a sugerir una relacion de n a n

Tabla mal diseniada
id_articulo
descripcion
parte1
parte2
parte3

Tabla original
id_articulo
descripcion

Tabla parte
id_parte
parte

relacion
id_articulo
id_parte

Esto no lo hace.

Asi que te sugiero dbdesign4 si lo quieres ver de modo
grafico y analizalo tu.

Atte.
Gabriel Hermes Colina Zambra.

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

On 5/25/07, Gabriel Hermes Colina Zambra <hermeszambra(at)yahoo(dot)com> wrote:
>
> --- Jaime Casanova <systemguards(at)gmail(dot)com> escribió:
>
> > On 5/25/07, jlcambero <jlcambero(at)emergya(dot)es> wrote:
> > > Buenas lista, estoy diseñando un modelo bastante
> > grande para postgresql y me
> > > gustaria saber si existe algun programa para
> > comprobar si esta normalizado.
> > >
> >
> Lo maximo que he visto al respecto es la posibilidad
> de que una herramienta te sugiera dividir una tabla,
> para evitar redundancias, por ejemplo.
>
> id_articulo
> descripcion
> modelo
> marca
> precio
>
> La herramienta te sugeriria que hagas tres tablas
>
> Tabla origen
> id_articulo
> descripcion
> id_marca
> id_modelo
> precio
>
> Sugeridas
> Id_marca, marca
> id_modelo,modelo
>

y en base a que decide que se deben hacer las otras tablas? es decir
como sabe que marca y modelo son valores que se van a repetir?

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

--- Jaime Casanova <systemguards(at)gmail(dot)com> escribió:

> On 5/25/07, Gabriel Hermes Colina Zambra
> <hermeszambra(at)yahoo(dot)com> wrote:
> >
> > --- Jaime Casanova <systemguards(at)gmail(dot)com>
> escribió:
> >
> > > On 5/25/07, jlcambero <jlcambero(at)emergya(dot)es>
> wrote:
> > > > Buenas lista, estoy diseñando un modelo
> bastante
> > > grande para postgresql y me
> > > > gustaria saber si existe algun programa para
> > > comprobar si esta normalizado.
> > > >
> > >
> > Lo maximo que he visto al respecto es la
> posibilidad
> > de que una herramienta te sugiera dividir una
> tabla,
> > para evitar redundancias, por ejemplo.
> >
> > id_articulo
> > descripcion
> > modelo
> > marca
> > precio
> >
> > La herramienta te sugeriria que hagas tres tablas
> >
> > Tabla origen
> > id_articulo
> > descripcion
> > id_marca
> > id_modelo
> > precio
> >
> > Sugeridas
> > Id_marca, marca
> > id_modelo,modelo
> >
>
> y en base a que decide que se deben hacer las otras
> tablas? es decir
> como sabe que marca y modelo son valores que se van
> a repetir?
>
> --
> Atentamente,
> Jaime Casanova
>
> "Programming today is a race between software
> engineers striving to
> build bigger and better idiot-proof programs and the
> universe trying
> to produce bigger and better idiots.
> So far, the universe is winning."
> Richard Cook
>
Analiza un grupo de datos previamente insertados y te
los sugiere en base a analizar si los datos se pueden
repetir y si es asi te sugiere creacion de tablas, una
de esas herramientas es access.
Proba en herramientas analizar tabla con unos pocos
datos y fijate.

Igual te digo esto es muy pobre y no lo tendria en
consideracion, si lo que te muestra no lo pudiste
resolver pensando, deberia uno pensar si mejor no se
dedica a algo manual.

Atte.
Gabriel Hermes Colina Zambra

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

On 5/26/07, Gabriel Hermes Colina Zambra <hermeszambra(at)yahoo(dot)com> wrote:
> > > --- Jaime Casanova <systemguards(at)gmail(dot)com>
> > escribió:
> > > > > Buenas lista, estoy diseñando un modelo
> > bastante
> > > > grande para postgresql y me
> > > > > gustaria saber si existe algun programa para
> > > > comprobar si esta normalizado.
> > > > >
> > > >
> > > Lo maximo que he visto al respecto es la
> > posibilidad
> > > de que una herramienta te sugiera dividir una
> > tabla,
> > > para evitar redundancias, por ejemplo.
> > >
> >
> > y en base a que decide que se deben hacer las otras
> > tablas? es decir
> > como sabe que marca y modelo son valores que se van
> > a repetir?
> >
> >
> Analiza un grupo de datos previamente insertados y te
> los sugiere en base a analizar si los datos se pueden
> repetir y si es asi te sugiere creacion de tablas, una
> de esas herramientas es access.

Y luego te toca decidir a ti si la sugerencia es valida...
Teniendo los datos a la mano, eso lo hago yo mismo... dejarselo a un
programa me parece muy propenso a errores...

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook

--- Jaime Casanova <systemguards(at)gmail(dot)com> escribió:

> On 5/26/07, Gabriel Hermes Colina Zambra
> <hermeszambra(at)yahoo(dot)com> wrote:
> > > > --- Jaime Casanova <systemguards(at)gmail(dot)com>
> > > escribió:
> > > > > > Buenas lista, estoy diseñando un modelo
> > > bastante
> > > > > grande para postgresql y me
> > > > > > gustaria saber si existe algun programa
> para
> > > > > comprobar si esta normalizado.
> > > > > >
> > > > >
> > > > Lo maximo que he visto al respecto es la
> > > posibilidad
> > > > de que una herramienta te sugiera dividir una
> > > tabla,
> > > > para evitar redundancias, por ejemplo.
> > > >
> > >
> > > y en base a que decide que se deben hacer las
> otras
> > > tablas? es decir
> > > como sabe que marca y modelo son valores que se
> van
> > > a repetir?
> > >
> > >
> > Analiza un grupo de datos previamente insertados y
> te
> > los sugiere en base a analizar si los datos se
> pueden
> > repetir y si es asi te sugiere creacion de tablas,
> una
> > de esas herramientas es access.
>
> Y luego te toca decidir a ti si la sugerencia es
> valida...
> Teniendo los datos a la mano, eso lo hago yo
> mismo... dejarselo a un
> programa me parece muy propenso a errores...
>
> --
> Atentamente,
> Jaime Casanova
>
> "Programming today is a race between software
> engineers striving to
> build bigger and better idiot-proof programs and the
> universe trying
> to produce bigger and better idiots.
> So far, the universe is winning."
> Richard Cook
>
Por supuesto yo no lo uso y por eso decia que lo que
mas se acercaba a la consulta original era esto y
estoy casi seguro que no te sirve para n a n. Lo hice
notar por que no puede existir un normalizador que
haga el disenio por uno, sin consultar decisiones y lo
mas parecido que he visto es esto, pensado para
usuarios de pc de escritorio y no para
desarrolladores.

Si me gusta la representacion grafica que tiene MSSQL,
cosa que en PostgreSQL la sustituyo pauperrimamente o
con el EMS pago o con Dbdesigner4, pues me gusta
mostrar el modelo de datos a mis clientes y razonarlo
con ellos en desarrollos a medida.

Por supuesto que para la normalizacion prefiero
desidir yo y tambien despues para la desnormalizacion.

Atte.
Gabriel

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

Gabriel Hermes Colina Zambra dijo [Sat, May 26, 2007 at 05:09:43PM -0500]:
> Si me gusta la representacion grafica que tiene MSSQL,
> cosa que en PostgreSQL la sustituyo pauperrimamente o
> con el EMS pago o con Dbdesigner4, pues me gusta
> mostrar el modelo de datos a mis clientes y razonarlo
> con ellos en desarrollos a medida.

Asómate a postgresql-autodoc, es una verdadera chulada.

http://www.rbt.ca/autodoc/

> Por supuesto que para la normalizacion prefiero
> desidir yo y tambien despues para la desnormalizacion.

Claro, son actividades que requieren de intervención humana, de
inteligencia. Cualquier inferencia automática va a resultar incompleta
o sobrecompleta.

--
Gunnar Wolf - gwolf(at)gwolf(dot)org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

--- Gunnar Wolf <gwolf(at)gwolf(dot)org> escribió:

> Gabriel Hermes Colina Zambra dijo [Sat, May 26, 2007
> at 05:09:43PM -0500]:
> > Si me gusta la representacion grafica que tiene
> MSSQL,
> > cosa que en PostgreSQL la sustituyo
> pauperrimamente o
> > con el EMS pago o con Dbdesigner4, pues me gusta
> > mostrar el modelo de datos a mis clientes y
> razonarlo
> > con ellos en desarrollos a medida.
>
> Asómate a postgresql-autodoc, es una verdadera
> chulada.
>
> http://www.rbt.ca/autodoc/
>
> > Por supuesto que para la normalizacion prefiero
> > desidir yo y tambien despues para la
> desnormalizacion.
>
> Claro, son actividades que requieren de intervención
> humana, de
> inteligencia. Cualquier inferencia automática va a
> resultar incompleta
> o sobrecompleta.
>
> --
> Gunnar Wolf - gwolf(at)gwolf(dot)org - (+52-55)5623-0154 /
> 1451-2244
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E
> F35A 8BB5 27AF
>
> ---------------------------(fin del
> mensaje)---------------------------
> TIP 8: explain analyze es tu amigo
>
Gracias Gunnar, excelente aporte, lo probare en linux,
puesto que no vi una opcion para windows, pero por lo
que lei parece prometedor.

Muchas Gracias

Atte.
Gabriel Hermes Colina Zambra

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/

El 9/05/07, WILLIAM PARRA <wilparra(at)yahoo(dot)com> escribió:
> En Oracle Si.

Tanto en Oracle como en PostgreSQL (creo) no se puede ejecutar código
PL/loquesea fuera de PL/loquesea .

Lo que si se puede hacer es código SQL .

Y que me corrijan los que saben mas que yo :-)

--
----o---( )---o----
Saludos de Victor Lopez Sabio
d01m01a2000(at)gmail(dot)com
--------oooo--------

Victor Lopez escribió:
> El 9/05/07, WILLIAM PARRA <wilparra(at)yahoo(dot)com> escribió:
> >En Oracle Si.
>
> Tanto en Oracle como en PostgreSQL (creo) no se puede ejecutar código
> PL/loquesea fuera de PL/loquesea .

En Oracle si se puede ejecutar PL/SQL en bloques anonimos, directamente,
sin necesidad de crear una funcion.

--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)

El 15/06/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> escribió:
> Victor Lopez escribió:
> > El 9/05/07, WILLIAM PARRA <wilparra(at)yahoo(dot)com> escribió:
> > >En Oracle Si.
> >
> > Tanto en Oracle como en PostgreSQL (creo) no se puede ejecutar código
> > PL/loquesea fuera de PL/loquesea .
>
> En Oracle si se puede ejecutar PL/SQL en bloques anonimos, directamente,
> sin necesidad de crear una funcion.

Cierto.

Yo es que confundo las parejas BEGIN/END de una transacción, en
PostgreSQL, con BEGIN/END de un bloque anónimo en Oracle.

> --
> Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
> Maybe there's lots of data loss but the records of data loss are also lost.
> (Lincoln Yeoh)
>

--
----o---( )---o----
Saludos de Victor Lopez Sabio
d01m01a2000(at)gmail(dot)com
--------oooo--------