pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Is it possible to speed this query up?
2+ messages / 2 participants
[nested] [flat]

* Is it possible to speed this query up?
@ 2006-07-26 17:01  Arnau <arnaulist@andromeiberica.com>
  0 siblings, 1 reply; 2+ messages in thread

From: Arnau @ 2006-07-26 17:01 UTC (permalink / raw)
  To: pgsql-performance

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



^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Is it possible to speed this query up?
@ 2006-07-26 20:24  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Arnau <arnaulist@andromeiberica.com>
  0 siblings, 0 replies; 2+ messages in thread

From: Tom Lane @ 2006-07-26 20:24 UTC (permalink / raw)
  To: arnaulist@andromeiberica.com; +Cc: pgsql-performance

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



^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2006-07-26 20:24 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-07-26 17:01 Is it possible to speed this query up? Arnau <arnaulist@andromeiberica.com>
2006-07-26 20:24 ` Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox