Skip site navigation (1) Skip section navigation (2)

Re: [pgsql-es-ayuda] ejecucion de sentencias update de manera mas veloz

From: Juan <smalltalker(dot)marcelo(at)gmail(dot)com>
To: Armando Venegas Pérez <venegasp_armando(at)hotmail(dot)com>
Cc: pgsql-es-ayuda(at)postgresql(dot)org, arpug(at)postgresql(dot)org
Subject: Re: [pgsql-es-ayuda] ejecucion de sentencias update de manera mas veloz
Date: 2012-06-25 22:15:18
Message-ID: CAKizN9wpzWiVRFK9OHb5L5y64rjVmBG52hr5-+fm8T+SQhwK3A@mail.gmail.com (view raw or flat)
Thread:
Lists: arpugpgsql-es-ayudapgsql-es-fomento
Gente

cuelo una idea que podria ser beneficiosa, si el '99'  es un código o
alguna condicion
que establezca separación en tus datos algo que andaria de maravillas seria
hacer un indice con where ,supongamos que la tabla es clientes, y el campo
id,

create index i_99 on clientes( id, nombre_cliente) where
 "SUBSTR(id,1,2)='99'"   ;

"chequear sintax"

seguramente posiblemente el plan se vea tentado a usar este indice .
quizas con el like no funciones o quizas tratar de poner en el where del
indice like
pero creo que like no lo indexa.
mis 2cvos

salu2
jmdc.

2012/6/25 Armando Venegas Pérez <venegasp_armando(at)hotmail(dot)com>

>  Hola Gilberto.
>
> Espero que mis comentarios ayuden a resolver tu necesidad.
>
> Para comenzar, una de las cosas más pesadas para cualquier  BD es el
> UPDATE, así que no te preocupes.
>
> Si es más rápido: "SUBSTR(id,1,2)='99'"   que "id LIKE '99%'" por
> milésimas de segundo. Mejora pero no es de gran ayuda a tu problema.
>
> Algo mas útil sería algo así "id_ini=99". Es decir agregar un campo
> adicional donde guardes los primeros dos dígitos en valor numérico, y
> además agregarle un índice a este campo.
> Pero es algo que tendrás que ver con tu DBA y con tus compañeros de
> programación (Si es que existen).
>
> Otra cosa es el comparar "nom_cli='UN VALOR ALFANUMÉRICO'".
> Si puedes y tienes, sería mejor comparar "id_cli=77594830". Es más rápido
> un filtro por número, que por alfanumérico.
> Si no tienes un ID para CLIENTE, entonces agrega un índice a NOM_CLI para
> que la búsqueda sea más rápida.
>
> Otra cosa sería el orden del WHERE, escribe los filtros de menor a mayor
> tiempo de consulta.
> Es decir, al tanteometro cual filtro regresa más rápido el resultado:
> "nom_cli='HOSTAL CABALLITO TOTORA'"  ó "SUBSTR(id,1,2)='99'" , ese debe ir
> primero.
> Si logras crear el campo "id_ini" del tipo numérico y con índice, pon este
> primero.
>
>
> ------------------
> Si quieres algo extremo es crear una nueva tabla con los valores
> actualizados, algo así: (Un INSERT es más rapido)
>
> CREATE TABLE cat_lote_2 AS
> SELECT campo1, campo2,
>   CASE WHEN SUBSTR(ID,1,2)='99' THEN '13'||SUBSTR(ID,2)
>              ELSE  ID
>   END AS campo3,
>   campo4, campo5, etc....
> FROM cat_lote;
>
> (Lo anterior si aplica a tus necesidades)
>
> Una vez creada esta tabla, le agregas sus índices y llaves primarias y
> foráneas, y la renombras como la tabla correcta.
> ------------------
>
>
> Otra cosa por experiencia es el espacio disponible en tu Disco Duro.
>
> Por último y por mi experiencia, siento que ejecutar un lote de SQL es más
> rápido desde PSQL que desde PgAdmin
>
>
>
> Espero te pueda ayudar.
> Saludos
>
> ------------------------------
> Date: Mon, 25 Jun 2012 10:37:56 -0500
> Subject: [pgsql-es-ayuda] ejecucion de sentencias update de manera mas
> veloz
> From: jvenegasperu(at)gmail(dot)com
> To: pgsql-es-ayuda(at)postgresql(dot)org; pgsql-es-fomento(at)postgresql(dot)org;
> arpug(at)postgresql(dot)org
>
>
> Buen dia a todos
>
> tengo una base de datos postgis que tienen la lotizacion de un poblado
> pues resulta que cada fila de los lotes tiene el nombre del cliente pero no
> su codigo para otras consultas administrativas que tenemos
> en otro sistema alfanumerico
> asi que exporte la lista de nombres y codigos del sistema transaccional en
> oracle para insertarle ese codigo a postgres usando excel para armar la
> consulta.
>
> las consultas que genero en excel quedan asi:
>
> UPDATE CAT_LOTE SET ID= '13010400060' WHERE NOM_CLI = 'HOSTAL CABALLITO
> TOTORA' AND ID LIKE '99%';
> UPDATE CAT_LOTE SET ID= '13010400070' WHERE NOM_CLI = 'ARCILA GONZALES
> MARGOT IVONE' AND ID LIKE '99%';
> UPDATE CAT_LOTE SET ID= '13010400080' WHERE NOM_CLI = 'LESCANO ALVA CARLOS
> FORTUNATO' AND ID LIKE '99%';
> UPDATE CAT_LOTE SET ID= '13010400090' WHERE NOM_CLI = 'ARCILLA CACERES
> MICAELA' AND ID LIKE '99%';
> UPDATE CAT_LOTE SET ID= '13010400100' WHERE NOM_CLI = 'ARCILLA JURADO
> ALBERTO' AND ID LIKE '99%';
>
> y asi hasta 200 mil
>
> estas las pego en el pgadmin pero en bloques de 10000 porque si le pongo
> mas se cuelga y demora una hora mas o menos en ejecutar esa actualizacion.
>
> estoy usando postgres 9.1 sobre windows server 2003
>
> alguna otra forma de hacer esto mas rapido usando el psql por consola no
> se alguna otra forma como seria?
>
> gracias por la atencion
>
> saludos
>
> --
> José Mercedes Venegas Acevedo
> cel: Mov. 949808846
>
> mails: jvenegasperu(at)php(dot)net
>           jvenegasperu(at)gmail(dot)com
>
> PHP Spanish Docs translator member.
> http://www.php.net/manual/es/index.php
>
>

In response to

Responses

pgsql-es-fomento by date

Next:From: Alvaro HerreraDate: 2012-06-25 22:49:28
Subject: Re: [pgsql-es-ayuda] ejecucion de sentencias update de manera mas veloz
Previous:From: =?iso-8859-1?B?QXJtYW5kbyBWZW5lZ2FzIFDpcmV6?=Date: 2012-06-25 19:27:46
Subject: Re: [pgsql-es-ayuda] ejecucion de sentencias update de manera mas veloz

pgsql-es-ayuda by date

Next:From: Alvaro HerreraDate: 2012-06-25 22:49:28
Subject: Re: [pgsql-es-ayuda] ejecucion de sentencias update de manera mas veloz
Previous:From: Alejandro CarrilloDate: 2012-06-25 21:07:41
Subject: Re: permisos

arpug by date

Next:From: Alvaro HerreraDate: 2012-06-25 22:49:28
Subject: Re: [pgsql-es-ayuda] ejecucion de sentencias update de manera mas veloz
Previous:From: =?iso-8859-1?B?QXJtYW5kbyBWZW5lZ2FzIFDpcmV6?=Date: 2012-06-25 19:27:46
Subject: Re: [pgsql-es-ayuda] ejecucion de sentencias update de manera mas veloz

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group