Re: Encontrar una manera menos intensiva de hacer una consulta

Alvaro Herrera dijo [Tue, Mar 14, 2017 at 04:07:35PM -0300]:
> > Creo que con esto podemos seguir trabajando. ¡A estudiar funciones
> > sobre arreglos!
>
> Creo que lo que más te puede ayudar en este caso es "scalar op array
> expression", donde tienes un valor escalar, un operador, y un array.
> No sé si hay más casos que estos dos:
>
> escalar = ANY (array)
> escalar <> ALL (array)
> el operador puede ser cualquier cosa, no solo = o <>;
> el escalar puede ser una columna de una tabla.
>
> La primera retorna TRUE si cualquier elemento del array es igual al
> escalar. La segunda retorna TRUE si todos los elementos del array son
> <> al escalar.
>
> El "scalar op array expr" es un caso específicamente optimizado --
> particularmente con btrees.

OK, si está específicamente optimizado, buscaré utilizarlo. Por ahora,
hice un par de consultas (que me dejaron satisfecho) especificando mi
escalar explícitamente como arreglo. Obviamente sucio, porque sólo
estoy jugando:

SELECT * FROM (
SELECT email, array_agg(show_keyid(keyid)) AS keys,
cardinality(array_agg(show_keyid(keyid))) as numkeys
FROM pubkey_metadata GROUP BY email) AS set
WHERE keys && array['673a03e4c1db921f'];

SELECT * FROM (
SELECT email, array_agg(show_keyid(keyid)) AS keys,
cardinality(array_agg(show_keyid(keyid))) as numkeys
FROM pubkey_metadata GROUP BY email) AS set
WHERE '673a03e4c1db921f' = ANY(keys);

Comparando sus query plans y tiempos de ejecución me parecen casi
sinónimos. Pero, sí, la versión con ANY resulta un poco más legible y
clara para el humano, que no es poca cosa :)

(¿que por qué usé un subquery para algo tan trivial como esto? Porque
si no, el ANY(keys) se quejaba de que keys no existía, y no puedo
incluir una función en el WHERE).

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda