> On 9/06/2023, at 11:29 AM, Guillermo E. Villanueva <guillermo...@gmail.com> > wrote: > > Hola Horacio, muchas gracias por responder, van mis rtas: > > > El vie, 9 jun 2023 a las 12:18, Horacio Miranda (<hmira...@gmail.com > <mailto:hmira...@gmail.com>>) escribió: > No puedes insertar los datos en el tipo de dato de destino ? > de hecho eso hago, al insertar los datos llamo a la función que a partir de > un id de large object trae un bytea > si quieres podemos hacer un lab. manda un email por probado, hoy tengo tiempo, de hecho estoy en Chile :D > > > Evita funciones have todo por SQL las funciones te matan el performance > siempre. > Perdon mi ignorancia, que son las funciones "have todo" como me recomiendas > que haga en este caso? have= hace, la idea es no usar funciones, debes hacer todo lo posible solo con SQL.
Ahora que te dice el plan de ejecución? explain (buffers,analyze) SELECT …. los resultados puedes dejarlos en https://explain.depesz.com/ > > > > Regards, > Horacio Miranda > > >> On 9/06/2023, at 10:58 AM, Guillermo E. Villanueva <guillermo...@gmail.com >> <mailto:guillermo...@gmail.com>> wrote: >> >> >> Hola amigos cómo están? les pido ayuda, tengo una muy baja performance en un >> proceso masivo que tengo que hacer, lamentablemente es postgres 9.2 ya que >> dependemos de un 3ro. >> >> Entiendo si por la versión no pueden o no quieren aportar. >> >> Cómo los datos originales tenían una columna lo (large object) los tengo que >> pasar a bytea, para eso utilizo la función: >> CREATE OR REPLACE FUNCTION public.bytea_import(IN l_oid oid, OUT p_result >> bytea) RETURNS bytea AS >> $BODY$ >> declare >> r record; >> begin >> p_result := E'\\x'; >> for r in ( select data >> from pg_catalog.pg_largeobject >> where loid = l_oid >> order by pageno ) loop >> p_result = p_result || r.data; >> end loop; >> end; >> $BODY$ >> LANGUAGE plpgsql; >> >> El explain de la query dentro de la función es: >> "Index Scan using pg_largeobject_loid_pn_index on pg_largeobject >> (cost=0.00..1307.84 rows=2238 width=1093)" >> " Index Cond: (loid = 123123123::oid)" >> >> Creo una tabla similar a la original solo que la columna de tipo lo, ahora >> es bytea y luego recorro la tabla gande con una columna de tipo lo para >> convertirla en bytea , lo hago con la siguiente función: >> CREATE OR REPLACE FUNCTION insertar_tca() RETURNS VOID AS $$ >> DECLARE >> ini_oid INT; >> min_oid INT; >> max_oid INT; >> batch_size INT := 10000; -- Tamaño del lote para cada actualización >> BEGIN >> SELECT MIN(oid), MAX(oid) INTO min_oid, max_oid FROM tca; >> ini_oid := min_oid; >> >> WHILE min_oid <= max_oid >> LOOP >> INSERT INTO tca_bytea >> SELECT org_codigo, tcc_codigo, hca_numero, dac_codigo, hac_numero, hca_anio, >> hac_anio, bytea_import(tca_texto) >> FROM tca >> WHERE oid >= min_oid AND oid < min_oid + batch_size; >> RAISE NOTICE '[%] Registros actualizados tca desde % hasta % - Total %', >> current_timestamp,min_oid, min_oid + batch_size, min_oid + batch_size - >> ini_oid; >> >> min_oid := min_oid + batch_size; >> END LOOP; >> END; >> $$ LANGUAGE plpgsql; >> >> Tengo un índice creado en la tabla origen por la columna oid y el explain >> del select principal de esa función es: >> "Bitmap Heap Scan on tca (cost=171.68..14074.21 rows=12854 width=30)" >> " Recheck Cond: ((oid >= 123123123::oid) AND (oid < 123133123::oid))" >> " -> Bitmap Index Scan on idx_oid_tca (cost=0.00..168.47 rows=12854 >> width=0)" >> " Index Cond: ((oid >= 123123123::oid) AND (oid < 123133123::oid))" >> >> >> El problema es que demora muchísimo!!! para hacer la primera vuelta de >> ciclo, es decir los primeros 10000 registros demoró poco mas de 1 hora y la >> tabla tiene 2.5 millones de registros :-( >> He probado también de hacerlo con una columna adicional en la misma tabla y >> con sentencia UPDATE, también probé de hacerlo sin particionarlo, en todos >> los casos va demasiado lento. >> >> Estoy haciendolo en un server linux con 128Gb de RAM y 32 nucleos y algunos >> de los parámetros de conf son: >> # Memory Configuration >> shared_buffers = 512MB >> effective_cache_size = 96GB >> work_mem = 459MB >> maintenance_work_mem = 6GB >> >> # Checkpoint Related Configuration >> checkpoint_completion_target = 0.9 >> wal_buffers = -1 >> checkpoint_segments = 16 >> >> # Network Related Configuration >> listen_addresses = '*' >> max_connections = 100 >> >> # Storage Configuration >> random_page_cost = 1.1 >> effective_io_concurrency = 200 >> >> Les agradezco mucho si me pueden tirar ideas o comentarios de que puede >> estar pasando. >> Abrazo >>
