"Yaroslav Mazurak" <[EMAIL PROTECTED]>
> Problem is that SQL statement (see below) is running too long. With
> current WHERE clause 'SUBSTR(2, 2) IN ('NL', 'NM') return 25 records.
> With 1 record, SELECT time is about 50 minutes and takes approx. 120Mb
> RAM. With 25 records SELECT takes about
From: ""Fernando Papa"" <[EMAIL PROTECTED]>
> AND upper(cont_publicacion.generar_Vainilla) = 'S'
> Filter: ((upper((generar_vainilla)::text) = 'S'::text) AND
(fecha_publicacion = (subplan)))
using a functional index on this field should help
create index idx_generar_vainilla_ci on cont_public
Hi all,
last week Josh Berkus point my attenction
( see post Wrong plan or what )
to the
fact that in this select:
select *
from user_logs ul,
user_data ud,
class_default cd
where
ul.id_user = ud.id_user and
ud.id_class = cd.id_class and
cd.id_provider = 39;
The planner
"Josh Berkus" <[EMAIL PROTECTED]>
> Gaetano,
>
> > QUERY PLAN
> > Hash Join (cost=265.64..32000.76 rows=40612 width=263) (actual
> > time=11074.21..11134.28 rows=10 loops=1)
> >Hash Cond: ("outer".id_user = "inner".id_user)
> >-> Seq Scan on user_logs ul (cost=0.00..24932.65 rows=125896
Forget my PS to last message.
---(end of broadcast)---
TIP 8: explain analyze is your friend
"Josh Berkus" <[EMAIL PROTECTED]>
> Gaetano,
>
> > SELECT * from user_logs where id_user in (
> > 10943, 10942, 10934, 10927, 10910, 10909
> > );
> > [SNIPPED]
>
> > Why the planner or the executor ( I don't know ) do not follow
> > the same strategy ?
>
> It is, actually, according to th
Hi all,
I'm running Postgres7.3.3 and I'm performing this simple select:
select *
from user_logs ul,
user_data ud,
class_default cd
where
ul.id_user = ud.id_user and
ud.id_class = cd.id_class and
cd.id_provider = 39;
these are the number of rows for each table:
user_logs
