On 22-Dec-07, at 7:14 PM, Michael Glaesemann wrote:
It may be that SQL is doing exactly as it should, since 'id' is in
scope within the subselect, but if that's the case it's a nasty
gotcha.
Yes, and yes.
Ow. Thanks for confirming both my suspicions and my fears :-)
R.
Hello
there is some differences:
ndex Scan using i_tablea_atextfield on tablea ru (cost= 0.00..2265.28
rows=2 width=12) (actual time=0.624..881.313 rows=228 loops=1)
Index Cond: (atextfield = 'thelookupval'::text)
Filter: ((achar1fi
On Dec 24, 2007 7:46 PM, Marc <[EMAIL PROTECTED]> wrote:
> Hey Folks,
>
> This query is running really slowly. Sometimes much slower then others. I
> have a feeling that there may be contention on one of the indices it is
> using. In the explain plan, it looks like it estimates 2 rows but actual
Hey Folks,
This query is running really slowly. Sometimes much slower then others. I
have a feeling that there may be contention on one of the indices it is
using. In the explain plan, it looks like it estimates 2 rows but actually
finds 228 rows? Is that really bad?
Query and explain plan a
tatistics s
> , statistics_sequence ss
> WHERE se.customer_app_config_id = 36052
> AND se.current_message_id = sm.sequence_message_id
> AND se.enduser_id = ss.enduser_id
> AND ss.statistic_id = s.statistic_id
> AND s.telecom_operator_id <> 0
> AND s.timestamp_in BETWEEN TO_TIMES
er_id = ss.enduser_id
AND ss.statistic_id = s.statistic_id
AND s.telecom_operator_id <> 0
AND s.timestamp_in BETWEEN TO_TIMESTAMP( '20071217 00', 'MMDD HH24'
) AND TO_TIMESTAMP( '20071224 13', 'MMDD HH24' )
GROUP BY se.enduser_id, se.enduser_nu
