Re: Funcion inet2int - error

> Rubén da Silva escribió:
>>>> Ahora que esto está solucionado, veo cuando la uso (con EXPLAIN ANALYZE)
>>>> que usa un "seq scan" en lugar de un "index scan".
>>>>
>>>> Para ponernos en situación:
>>>>
>>>> Imaginemos que tengo rangos de ips almacenados en una tabla como enteros
>>>> (int8) start y end.
>>>>
>>>> Tengo un index de estas columnas de enteros.
>>>
>>> Mala idea -- podrias almacenar las IPs usando el tipo "inet". Hay
>>> operadores para > y < para ese tipo que te facilitarian estas busquedas.
>>>
>> Los datos me los han dado así, por mi los almacenaría en inet que es lo
>> más lógico. La conversión me temo que puede ser mortal, son 3 millones *
>> 2 columnas = 6 millones de conversiones. Meter los datos con inserts me
>> llevaba varias horas, al final opté por COPY de un CSV y aún así le
>> llevó sus 10-15 minutos, ¿debería llevar poco (no horas) la conversión
>> si se trata de updates? (los metería en columnas de la misma tabla)
>
> Si puedes hacer una funcion barata que haga la conversion, no deberia
> demorarse mas de los 10-15 minutos de COPY. Pero te aconsejaria quitar
> todos los indices de la tabla, luego hacer el UPDATE, luego hacer
> VACUUM de la tabla, y finalmente volver a crear los indices.
>
>>>> SELECT id, blocks.ipnum_start, blocks.ipnum_end FROM blocks
>>>> WHERE inet2int('unaIP') > blocks.ipnum_start AND inet2int('unaIP') <
>>>> blocks.ipnum_end;
>>> Cual es la definicion de la tabla, y que version de Postgres estas
>>> usando?
>> CREATE TABLE blocks
>> (
>> ipnum_start int8 NOT NULL,
>> ipnum_end int8 NOT NULL,
>> loc_id int4 NOT NULL,
>> CONSTRAINT blocks_pkey PRIMARY KEY (loc_id, ipnum_start, ipnum_end)
>> )
>> WITHOUT OIDS;
>
> Los bloques esos, son CIDR propiamente tales, o son cualquier cosa? Se
> me ocurre que podrias solucionar esto de manera muy elegante usando un
> indice GiST que implementara pertenencia de una IP a un bloque; si es
> que los bloques estuvieran bien definidos.
>
> Quizas podrias hacerlo tambien si los bloques fueran cualquier cosa,
> pero no estoy seguro.
>
> Las direcciones son IPv4 o pueden ser IPv6 tambien? Hmm, las IPv6 son
> 128 bits asi que no cabrian en un int8 de todas formas, cierto?
>

De todas formas, digamos que el caso está resulto, guarde o no en int8 o
en inet ya sé como hacer para que la consulta se ejecute veloz, no
cómoda, pero si veloz.
Ahora el caso es... ¿porque existe ese comportamiento? ¿Como ejecuta
Postgres la funciones dentro de las consultas?. ¿Puede haber el mismo
problema con cualquier otra consulta que use funciones en su interior?
¿Como podría estudiarlo aparte de un EXPLAIN ANALYZE?