El día 18 de mayo de 2009 14:15, Alvaro Herrera
<[email protected]> escribió:
> Emanuel Calvo Franco escribió:
>
>> En ese caso no le conviene crear indices particionados?
>> i.e:
>> parapruebas=# create index ix_datos on datos (texto) where texto ~ 'a%';
>> CREATE INDEX
>> (es un ejemplo burdo, pero creo que se entiende :)
>
> No soluciona el problema, porque el problema es que el campo es muy
> largo. Lo que podría hacer es lo siguiente
>
Lei mal (lei cualquiera), habia entendido que el problema era la
cantida de filas, no el tamaño del campo. tenes razón...
> create index ix_substr_datos on datos (substring(1, 2000, texto));
> -- o como sea el orden de argumentos de substring
>
> y obviamente modificar las consultas para agregar un substring en el
> where también (además de la cláusula original).
>
Creo que para este caso sería conveniente que utilizará full text search, creo
que ya lo habias dicho.
>> Separar los indices en un tablespace alamcenado en un lugar
>> de más rápido acceso?
>
> Yo dudo mucho de la robustez de esta idea, porque si hay una caída
> tienes que corregir los catálogos y hacer un reindex.
>
No entiendo cual sería la inconsistencia, no ocurriría lo mismo si
tiene los índices en el lugar por defecto ?... (obviando el particionamiento)
--
Emanuel Calvo Franco
Sumate al ARPUG !
( www.arpug.com.ar)
ArPUG / AOSUG Member
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a [email protected])
