Re: Trabajando con Grandes BD

Asi es solo devuelve 3 registros.

On Thu, 15 Mar 2007, Oswaldo Hernández wrote:

> Vida Luz escribió:
>> Hola Oswaldo, si mejoro, el resultado ahora es:
>>
>> explain analyze select gr.geren_cod, count(gr.cliente_cod) from (select
>> geren_cod, cliente_cod from dm.venta group by geren_cod, cliente_cod) as gr
>> group by gr.geren_cod;
>> QUERY PLAN
>>
>> ----------------------------------------------------------------------------------------------------------------------------------
>> HashAggregate (cost=191715.06..191717.56 rows=200 width=14) (actual
>> time=33709.323..33709.336 rows=3 loops=1)
>> -> HashAggregate (cost=190715.06..191115.06 rows=40000 width=14)
>> (actual time=33612.347..33665.907 rows=10160 loops=1)
>> -> Seq Scan on venta (cost=0.00..180426.04 rows=2057804
>> width=14) (actual time=10.260..23092.667 rows=2057804 loops=1)
>> Total runtime: 33734.848 ms
>> (4 rows)
>>
>> el problema que tengo, es que usaron un servidor ocn las mismas
>> caracteriticas donde esta el postgres, instalaron un SQL Server sobre
>> windows 2003 server y ese select sin indexar lo hizo en 1.6 segundos, yo
>> nunca he usado MSSQL, solo he usado postgres y el problema que tengo es que
>> no tenemos recursos para comprar porductos windows.
>>
>> Como puedo llegar a obtener el mismo tiempo de MS-SQL para obtener el mismo
>> resultado ?
>>
>>
>
>
> Una cosa, no soy experto analizando los explain pero me da que esta consulta
> solo devuelve 3 registros. Por favor dime si es asi.
>
>
>
>
>
>
>>
>>
>> On Thu, 15 Mar 2007, Oswaldo Hernández wrote:
>>
>>> Vida Luz escribió:
>>>> con explain este es el costo que se tiene: aporx unos 2.7 minutos.
>>>>
>>>>
>>>>
>>>> c=# explain analyze SELECT count(distinct cliente_cod) FROM dm.venta
>>>> GROUP BY geren_cod;
>>>> QUERY PLAN
>>>>
>>>>
>>>> ---------------------------------------------------------------------------------------------------------------------------------
>>>> GroupAggregate (cost=421813.88..437247.45 rows=3 width=14) (actual
>>>> time=159638.993..165536.431 rows=3 loops=1)
>>>> -> Sort (cost=421813.88..426958.39 rows=2057804 width=14) (actual
>>>> time=152000.054..158792.629 rows=2057804 loops=1)
>>>> Sort Key: geren_cod
>>>> -> Seq Scan on venta (cost=0.00..180972.04 rows=2057804
>>>> width=14) (actual time=3.358..29855.519 rows=2057804 loops=1)
>>>> Total runtime: 166281.479 ms
>>>> (5 rows)
>>>>
>>>>
>>>
>>>
>>> Un poco por curiosidad, podrias probar estos select y decirnos si hay
>>> diferencias con ese volumen de datos:
>>>
>>> select
>>> gr.geren_cod, count(gr.cliente_cod)
>>> from (select geren_cod, cliente_cod from dm.venta group by geren_cod,
>>> cliente_cod) as gr
>>> group by gr.geren_cod
>>>
>>>
>>> select
>>> gr.geren_cod, count(gr.cliente_cod)
>>> from (select distinct geren_cod, cliente_cod from dm.venta) as gr
>>> group by gr.geren_cod
>>>
>>>
>>> Gracias.
>>>
>>>
>>>
>> ---------------------------(fin del mensaje)---------------------------
>> TIP 7: no olvides aumentar la configuración del "free space map"
>>
>
>
>
>From pgsql-es-ayuda-owner(at)postgresql(dot)org Thu Mar 15 20:44:03 2007
Received: from localhost (maia-4.hub.org [200.46.204.183])
by postgresql.org (Postfix) with ESMTP id 49F3A9FB70B
for <pgsql-es-ayuda-postgresql(dot)org(at)postgresql(dot)org>; Thu, 15 Mar 2007 20:44:03 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024)
with ESMTP id 62598-01 for <pgsql-es-ayuda-postgresql(dot)org(at)postgresql(dot)org>;
Thu, 15 Mar 2007 20:43:59 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from lafa.iiec.unam.mx (lafa.iiec.unam.mx [132.248.72.141])
by postgresql.org (Postfix) with ESMTP id 279FE9FB6F8
for <pgsql-es-ayuda(at)postgresql(dot)org>; Thu, 15 Mar 2007 20:43:58 -0300 (ADT)
Received: from localhost (localhost.localdomain [127.0.0.1])
by lafa.iiec.unam.mx (Postfix) with ESMTP id EEB0C30027FF;
Thu, 15 Mar 2007 17:46:08 -0600 (CST)
Received: from lafa.iiec.unam.mx ([127.0.0.1])
by localhost (lafa.iiec.unam.mx [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 14774-07; Thu, 15 Mar 2007 17:46:08 -0600 (CST)
Received: from gwolf.org (unknown [189.136.145.91])
by lafa.iiec.unam.mx (Postfix) with ESMTP id CE66030027E7;
Thu, 15 Mar 2007 17:46:07 -0600 (CST)
Received: by gwolf.org (Postfix, from userid 1000)
id BC4DB1817979; Thu, 15 Mar 2007 17:25:05 -0600 (CST)
Date: Thu, 15 Mar 2007 17:25:05 -0600
From: Gunnar Wolf <gwolf(at)gwolf(dot)org>
To: Henry <hensa22(at)yahoo(dot)es>
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Simbolos dentro de cadenas
Message-ID: <20070315232505(dot)GA13933(at)gwolf(dot)org>
References: <20070315001240(dot)GH11425(at)gwolf(dot)org> <977021(dot)34795(dot)qm(at)web30808(dot)mail(dot)mud(dot)yahoo(dot)com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <977021(dot)34795(dot)qm(at)web30808(dot)mail(dot)mud(dot)yahoo(dot)com>
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at iiec.unam.mx
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.24 tagged_above=0 required=5 tests=AWL, BAYES_50,
FORGED_RCVD_HELO
X-Spam-Level:
X-Archive-Number: 200703/571
X-Sequence-Number: 25826

Henry dijo [Thu, Mar 15, 2007 at 07:53:30AM +0100]:
> bueno, para comenzar no me gusta usar trigger, tambien soy poco de
> usar vista, ya que cuando hay pocos datos en la BD son buenas pero
> cuando la informacion va creciendo se ponen algo lentas, se refiero a
> las vistas.

Humh... Las vistas tienden a ser muy eficientes, según lo que yo he
podido observar :) Mi recomendación va más bien porque rara vez vale
la pena la rigidez que te impone _una_ consulta prefabricada - pero si
la requieres, para algo son!

> que raro que digas que no se obtiene alguna ventajas en rendimientos
> al usar funciones, o es mejor hacer 5 select seguidos en el cliente
> para validar datos antes de un insert, update o delete (osea
> aumentar el trafico de la red, imaginate en ambiente web). Ademas de
> mencionar los planes de ejecucion para las funciones.

No, claro, si vas a hacer una secuencia de operaciones, adelante, crea
una función. Sin emabrgo, si vas a hacer algo como:

CREATE FUNCTION registra_hijo (integer, integer) AS $$
DECLARE
padre ALIAS FOR $1,
hijo ALIAS FOR $2,
BEGIN
INSERT INTO relaciones (id_padre, id_hijo) VALUES (padre, hijo);
END
$$ language 'plpgsql';

Pues... ¿qué sentido tiene? Y créeme, me he encontrado con muchos
casos como este, en que el programador cree de este modo estar
"empujando" la lógica a la BD. Creo que tendría mayor sentido, en tu
clase Cosa, tener:

sub agrega_hijo {
my ($self, $hijo) = @_;
my $sth = $self->{db}->prepare('INSERT INTO relaciones (id_padre, id_hijo) VALUES (?,?)');
$sth->execute($self->{id}, $hijo->{id});
}

por poner un ejemplo simplista, claro está ;-)

> Tambien por
> cuestiones de seguridad el poner los nombres de columnas y tablas en
> tu codigo fuente, asi como tambien el usuario no esta trabajando
> directamente con la tabla sino con las funciones lo cual hace menos
> posible algun ataque de inyección SQL y se le puede asignar
> privilegios a las funciones sin ningun problema.

Momento, momento... Acá estás confundiendo peras con gimnasia. Para
evitar inyección de SQL, lo que debes hacer es evitar meter cualquier
elemento proporcionado por el usuario a tus cadenas SQL - ¿cómo?
Preparando las órdenes antes de ejecutarlas (puedes verlo en la
función que hice). En realidad, tener una aplicación completa que no
maneje SQL en lo más mínimo, es demasiado pedir... Es casi casi como
programar una aplicación que no conozca la estructura de los datos que
maneja. Ni siquiera con frameworks (p.ej. Rails) que hacen lo posible
por evitarte escribir el SQL directamente - los nombres de las
tablas y columnas siempre son fundamentales para tu código. Puedes,
sí, mantener diferentes órdenes ejecutadas por diferentes usuarios, o
cosas por el estilo.

> Tampoco hay que
> preocuparse por los caracteres especiales ya sea '\ @ä$:¨^ al hacer
> un update,delete o insert.

Nuevamente: Prepara una cadena SQL sin elementos externos. Ejecuta con
los datos proporcionados por el usuario. No hay posibilidad de
inyección de SQL.

> El uso de manejo de transacciones,
> donde mi lema es 'O se hace todo lo necesario o nada se hace' es
> obvio que por motivos de integridad de datos.

Completamente de acuerdo en esto - No lo incluí en la funcioncita de
arriba para mantenerla sencilla, pero sí, cualquier cosa que ocupe más
de una operación a la BD debe ir en una transacción

> Que la logica del negocio se encuentre
> centralizada asi que no solamente puede ser utilizada por una
> aplicacion sino por varias otras que la necesiten.

Acá... A veces y a veces. Depende de cada caso. Por ejemplo, en mi
caso, yo uso la BD principalmente como un depósito de datos
estructurados (y con algunos triggers mantengo pedacitos de esa
estructura que no son representables fácilmente en el DDL). Hago una
capa back-end en mi lenguaje de preferencia, que representa lo que les
ha dado por llamar la «lógica del negocio» (¡Dios me libre de hacer
negocios! ;-) ), y hago otra capa que se encarga de la interacción con
el usuario. O, cuando escribo con Ruby, me ciño al tradicional patrón
MVC, usando a la BD estrictamente como la mitad de abajo del modelo.

> Sobre porque uso 'select ' para retornar datos desde una funcion, es
> por ke no uso vistas, como dije anteriormente al comienzo son buenas
> pero cuando la informacion crece se ponen un poco lentas (eso sucede
> en cualquier DBMS).Y claro a veces debo hacer una consulta previa a
> la principal. (trafico de red) .

Vistas bien definidas, con índices bien definidos, no deben darte
mayor problema de rendimiento. Al menos, no un problema mayor que
hacer esa misma consulta desde la aplicacíon ;-)

Saludos,

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