Обсуждение: Is it possible to speed this query up?

Hi all,

   I execute the following query on postgresql 8.1.0:

SELECT
   u.telephone_number
   , u.telecom_operator_id
   , u.name
FROM
   campanas_subcampaign AS sub
   , agenda_users AS u
   , agenda_users_groups ug
WHERE
   sub.customer_app_config_id = 19362
   AND sub.subcampaign_id = 9723
   AND ug.agenda_user_group_id >= sub.ini_user_group_id
   AND ug.user_id=u.user_id
   AND ug.group_id IN ( SELECT group_id FROM campanas_groups WHERE
customer_app_config_id = 19362 )
   ORDER BY ug.agenda_user_group_id ASC LIMIT 150

the explain analyze shouts the following:



    Limit  (cost=1.20..4600.56 rows=150 width=74) (actual
time=76516.312..76853.191 rows=150 loops=1)
    ->  Nested Loop  (cost=1.20..333424.31 rows=10874 width=74) (actual
time=76516.307..76852.896 rows=150 loops=1)
          ->  Nested Loop  (cost=1.20..299653.89 rows=10874 width=20)
(actual time=76506.926..76512.608 rows=150 loops=1)
                Join Filter: ("outer".agenda_user_group_id >=
"inner".ini_user_group_id)
                ->  Nested Loop IN Join  (cost=1.20..189802.77
rows=32623 width=20) (actual time=75938.659..76353.748 rows=16200 loops=1)
                      Join Filter: ("outer".group_id = "inner".group_id)
                      ->  Index Scan using pk_agndusrgrp_usergroup on
agenda_users_groups ug  (cost=0.00..123740.26 rows=2936058 width=30)
(actual time=0.101..61921.260 rows=2836638 loops=1)
                      ->  Materialize  (cost=1.20..1.21 rows=1 width=10)
(actual time=0.001..0.002 rows=1 loops=2836638)
                            ->  Seq Scan on campanas_groups
(cost=0.00..1.20 rows=1 width=10) (actual time=0.052..0.053 rows=1 loops=1)
                                  Filter: (customer_app_config_id =
19362::numeric)
                ->  Index Scan using pk_cmpnssubc_subcmpnid on
campanas_subcampaign sub  (cost=0.00..3.35 rows=1 width=8) (actual
time=0.005..0.006 rows=1 loops=16200)
                      Index Cond: (subcampaign_id = 9723)
                      Filter: (customer_app_config_id = 19362::numeric)
          ->  Index Scan using pk_agenda_uid on agenda_users u
(cost=0.00..3.09 rows=1 width=78) (actual time=2.262..2.264 rows=1
loops=150)
                Index Cond: ("outer".user_id = u.user_id)
  Total runtime: 76853.504 ms
(16 rows)



Do you think I could do anything to speed it up?


Cheers!!
--
Arnau

Arnau <arnaulist@andromeiberica.com> writes:
> the explain analyze shouts the following:

The expensive part appears to be this indexscan:

>                       ->  Index Scan using pk_agndusrgrp_usergroup on
> agenda_users_groups ug  (cost=0.00..123740.26 rows=2936058 width=30)
> (actual time=0.101..61921.260 rows=2836638 loops=1)

Since there's no index condition, the planner is evidently using this
scan just to obtain sort order.  I think ordinarily it would use a
seqscan and then sort the final result, which'd be a lot faster if the
whole result were being selected.  But you have a LIMIT and it's
mistakenly guessing that only a small part of the table will need to be
scanned before the LIMIT is satisfied.

Bottom line: try dropping the LIMIT.  If you really need the limit to be
enforced on the SQL side, you could try declaring the query as a cursor
and only fetching 150 rows from it.

            regards, tom lane