Sorry Chris... a little slower...
esdc= EXPLAIN ANALYZE
SELECT
cont_contenido.id_contenido
,cont_contenido.pertenece_premium
,cont_contenido.Titulo_esp as v_sufix
,cont_contenido.url_contenido
,cont_contenido.tipo_acceso
,cont_contenido.id_sbc
,cont_contenido.cant_vistos
Hi Josh... a little worse time:
EXPLAIN ANALYZE
SELECT
cont_contenido.id_contenido
,cont_contenido.pertenece_premium
,cont_contenido.Titulo_esp as v_sufix
,cont_contenido.url_contenido
,cont_contenido.tipo_acceso
,cont_contenido.id_sbc
,cont_contenido.cant_vistos
I create the index, but doesn't help too much:
QUERY
PLAN
Title: Mensaje
Hi
Volker!!! I think you're right. Look at times:
QUERY
PLAN
---Limit
(cost=23.37..23.37 rows=1 width=487)
Err... you're right... one of us say the same thing when I show the
Volker mail...
-Mensaje original-
De: Manfred Koizar [mailto:[EMAIL PROTECTED]
Enviado el: lunes, 04 de agosto de 2003 12:17
Para: Fernando Papa
CC: Volker Helm; [EMAIL PROTECTED]
Asunto: Re: [PERFORM] I can't wait too
Hello,
Note: there is a SQL question way at the bottom of this narrative :-)
Last week I asked about doing substring operations on very long strings
(10 million characters). I was given a suggestion to use EXTERNAL
storage on the column via the ALTER TABLE ... SET STORAGE command. In
one test
Scott Cain [EMAIL PROTECTED] writes:
At least this appears to work and is much faster, completing substring
operations like above in about 0.27 secs (that's about two orders of
magnitude improvement!)
I find it really, really hard to believe that a crude reimplementation
in plpgsql of the
On 4 Aug 2003, Jenny Zhang wrote:
On Mon, 2003-08-04 at 06:33, Manfred Koizar wrote:
| effective_cache_size | 1000
With 4GB of memory this is definitely too low and *can* (note that I
don't say *must*) lead the planner to wrong decisions.
I changed the default to
