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?
> 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?
> 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?
> 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
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo
agradecerán
