pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedIs 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>
2006-07-26 20:24 ` Re: Is it possible to speed this query up? Tom Lane <tgl@sss.pgh.pa.us>
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 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>
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