El 11 de diciembre de 2008 10:48, Emanuel Calvo Franco <
[EMAIL PROTECTED]> escribió:
> El día 11 de diciembre de 2008 14:18, Felipe de Jesús Molina Bravo
> <[EMAIL PROTECTED]> escribió:
> > Muchas gracias por el apoyo ... va mas detalle.
> >
> > La jerarquia esta implementada con una secuencia de farey. Este secuencia
> > utiliza un intervalo de numeros racionales (izquierdo y derecho). El
> numero
> > racional esta implementado como un tipo de dato en postgres (el codigo
> esta
> > en "C" y lo copie del manual de postgres). Tengo una tabla que tiene la
> > siguiente estructura (la tabla se llama pt_j_producto):
> >
> > - idproducto: integer (not null default
> > nextval('pt_j_producto_idproducto_seq'::regclass))
> > - izq: racional ( not null )
> > - der: racional (not null )
> > - padre:racional --este campo apunta al padre directo de un registro (lo
> > tengo para hacer algunas comprobaciones y para facilitar la inserción)
> > ..... otros campos....
> >
> > Los indices que tengo de esta tabla son:
> >
> > «pt_j_producto_pkey» PRIMARY KEY, btree (idproducto)
> > «pt_j_producto_farey» btree (izq, der)
> >
>
> por lo que estoy viendo estas utilizando btree. Para inserciones masivas...
> no
> te conviene utilizar hash?
no me acepta mi tipo de dato, el cual es "racional" ... muy probablemente le
falte mas programación
>
>
>
> > Tambien tiene un trigger al insertar que llena los atributos izq y der de
> la
> > tabla (el intervalo de farey)
> >
> > Para insertar tengo que proporcionar el padre(el cual ya debe existir en
> la
> > tabla) y el nuevo nodo. El codigo principal de la función es:
> >
> > FOR reg IN select j.izq,j.der
> > --obtiene toda una rama. izq_cat es la raiz
> de
> > una rama
> > from obt_rama( izq_cat, 'pt_j_producto'
> > ) as j,
> > --obtien el nivel del nodo del padre.
> tpadre
> > es el nodo padre.
> > --der_tpadre es el atributo "der" de tpadre
> > obt_nivel(tpadre, der_tpadre) nivel_tpadre
> > --filtra por todos los nodos que estan en el
> > mismo nivel
> > where nivel_tpadre = obt_nivel(j.izq, j.der)
> > LOOP
> > --codigo que hace algunas validaciones, por ejemplo que tengan la
> misma
> > ascencendencia,
> > etc....
> > ....
> > ....
> > --insertamos
> > insert into pt_j_producto( padre, .... )
> > values (reg.izq, .... );
> > returning izq into t_izq ;
> >
> > END LOOP;
> >
> > Llamo a mi función de la siguiente forma:
> >
> > aeevrm=# select insertar_cl_var_pt_jp ('(16, 17)'::racional, 13);
> >
> > e inicia la inserción ... pero de repente marca lo siguiente:
> >
> > NOTICE: 2262: variable (105813, 134521) -> izq : (166891, 212170)
> > ERROR: obt_izq-> El padre (426142, 541847) no existe en pt_j_producto
> > CONTEXT: PL/pgSQL function "inserta_farey" line 8 at assignment
> > sentencia SQL: «INSERT INTO pt_j_producto( padre, tiponodo, idvariable,
> > idvarclase,control) values ( $1 , '2' , $2 , $3 , '1' ) returning
> izq»
> > PL/pgSQL function "insertar_cl_var_pt_jp" line 74 at SQL statement
> >
>
> Por lo que veo existen trabajando dos funciones (una llamada por el trigger
> y otra es la que llamas)
> El 'padre' que no existe en el error... ya estaba insertado
> previamente a la ejecucion
> de la funcion? O es una tabla que ya tiene datos y estas agregando?
asi es ... ya estaba insertado.
>
>
> > Nota: El numero 2262 indica el numero de registro que se esta insertando.
> >
> > Este error lo despliega la funcion que se encarga de obtener el izq y der
> de
> > la tabla pt_j_producto, la cual se llama durante la inserción (trigger).
> Lo
> > que indica es que el nodo (426142, 541847) el cual es un padre no existe
> en
> > la relación pt_j_producto. Al buscar por este nodo obtengo:
> >
> > aeevrm=# select * from pt_j_producto where izq='(426142, 541847)';
> > idproducto | izq | der | padre | idvarclase | idclase | idvariable |
> > idvargeo | tiponodo | comportamiento | xml_reftemporal | control | html
> >
> ------------+-----+-----+-------+------------+---------+------------+----------+----------+----------------+-----------------+---------+------
> > (0 filas)
> >
> >
> > entonces hago un REINDEX a la tabla:
> >
> > aeevrm=# REINDEX TABLE pt_j_producto ;
> >
> > y vuelvo a ejecutar:
> >
> > aeevrm=# select * from pt_j_producto where izq='(426142, 541847)';
> > idproducto | izq | der | padre |
> > idvarclase | idclase | idvariable | idvargeo | tiponodo | comportamiento
> > | xml_reftemporal | control | html
> >
> ------------+------------------+------------------+-----------------+------------+---------+------------+----------+----------+----------------+-------------------------+---------+------
> > 52844 | (426142, 541847) | (328605, 417827) | (97537, 124020)
> > | | 517 | | | 4 |
> |
> > <rts id="37" comp="0"/> | 1 |
> > (1 fila)
> >
> > Es por eso que indico que se esta corrumpiendo el indice....o quizas sea
> > otro el problema ... alguna idea?
> >
> >
>
> clusterizaste los indices a las tablas?
dejame probarlo ....
>
>
> > gracias de antemano
> >
> >
> > PD. Disculpen por el top-posting pero imagine que sería mas claro de esta
> > forma
> >
> >
> >
> > El 11 de diciembre de 2008 7:11, Alvaro Herrera <[EMAIL PROTECTED]
> >
> > escribió:
> >>
> >> Felipe de Jesús Molina Bravo escribió:
> >>
> >> > Cuando el numero de registros insertados excede los 3300 marca un
> error
> >> > en
> >> > un indice que tengo y me corrompe mi índice
> >>
> >> ¿Cuál error? ¿Cómo sabes que el índice está corrupto?
> >
> >
> >
> >
> >
> >
> >>
> >> > ¿cuanto es el numero de registros que pueden ser insertados durante la
> >> > ejecución de una función en plpgsql o mas bién que parametro me
> permite
> >> > controlar lo anterior?
> >>
> >> No hay límite (salvo consideraciones como memoria disponible, pero no
> >> siempre aplican).
> >>
> >> --
> >> Alvaro Herrera
> >> http://www.flickr.com/photos/alvherre/
> >> "El sabio habla porque tiene algo que decir;
> >> el tonto, porque tiene que decir algo" (Platon).
> >
> >
>
>
>
> --
> Emanuel Calvo Franco
> Syscope Postgresql Consultant
> ArPUG / AOSUG Member
>
