Optimization disaster

From: Dietrich <hoglabogla(at)hotmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Optimization disaster
Date: 2002-10-16 13:49:46
Message-ID: 3DAD6E7A.1010805@hotmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-novice

At last I decided to post my problem here: I have a web application
running since one year on postgres 7.1.3 with good performance. Now
suddenly a query takes huge amounts of time: I tried to turn of
SEQ_SCAN, and it was fast again.

The following Query needs about 0,2 seconds with SEQ_SCAN set to OFF
and 150 seconds with SEQ_SCAN set to ON:

EXPLAIN
SELECT DISTINCT location_elem_id, locationseason_id, valid_from ,
valid_until, startday_exclude FROM bc_quicktravel
WHERE valid_until >= '2002-10-17' AND valid_from <= '2003-02-13' AND
attrib_id < 0
AND location_elem_id IN (SELECT elem_id FROM bc_catalog_x_elem
WHERE catalog_id IN
(186827,54786,186724,186829,73115,186831,186726,798429,186833,1368557,186728,186835,186837,186730,1821382,75083,297219,186732,63533,186781,75078,186736,902810,129859,1178799,186750,75281,1387815,54786,1368557,297219,1178799,936688,55706,132578,408097,132576,136852,160655,160657,160653,160665,73110,73115,1821382,1476580,1309559,1303367,1202899,1179539,1106603,1140768,950925,798429,902810,466934,334726,288050,197983,187203,186781,186783,186789,0,3011678,68214,54686,68414,68419)
AND active_from_time < '2002-10-16 23:59:59 +0200'
AND active_until_time > '2002-10-16 23:59:59 +0200'
AND elem_active_and_released = 't'
AND elem_type = 'location')
AND (package_elem_id <= 0
OR package_elem_id IN (SELECT elem_id FROM bc_catalog_x_elem
WHERE catalog_id IN
(186827,54786,186724,186829,73115,186831,186726,798429,186833,1368557,186728,186835,186837,186730,1821382,75083,297219,186732,63533,186781,75078,186736,902810,129859,1178799,186750,75281,1387815,54786,1368557,297219,1178799,936688,55706,132578,408097,132576,136852,160655,160657,160653,160665,73110,73115,1821382,1476580,1309559,1303367,1202899,1179539,1106603,1140768,950925,798429,902810,466934,334726,288050,197983,187203,186781,186783,186789,0,3011678,68214,54686,68414,68419)
AND active_from_time < '2002-10-16 23:59:59 +0200'
AND active_until_time > '2002-10-16 23:59:59 +0200'
AND elem_active_and_released = 't'
AND elem_type = 'travelpack')
)
AND valid_until > '2002-10-16 23:59:59 +0200'
AND package_elem_id < 0
ORDER BY location_elem_id, valid_from
;

(1) I get this with without SEQ_SCAN set to ON (150 sec):

Unique (cost=1946377.12..1946383.16 rows=48 width=35)
-> Sort (cost=1946377.12..1946377.12 rows=483 width=35)
-> Index Scan using quicktravel_inx011 on bc_quicktravel
(cost=0.00..1946355.60 rows=483 width=35)
SubPlan
-> Materialize (cost=520.03..520.03 rows=24 width=4)
-> Seq Scan on bc_catalog_x_elem
(cost=0.00..520.03 rows=24 width=4)
-> Seq Scan on bc_catalog_x_elem (cost=0.00..520.03
rows=455 width=4)

(2) I get this with without SEQ_SCAN set to OFF (0,2 sec):

Unique (cost=1677.70..1677.71 rows=1 width=36)
-> Sort (cost=1677.70..1677.70 rows=1 width=36)
-> Index Scan using quicktravel_inx011 on bc_quicktravel
(cost=0.00..1677.69 rows=1 width=36)
SubPlan
-> Materialize (cost=837.80..837.80 rows=25 width=4)
-> Index Scan using bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey on bc_catalog_x_elem
(cost=0.00..837.80 rows=25 width=4)
-> Materialize (cost=837.80..837.80 rows=371 width=4)
-> Index Scan using bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey,
bc_catalog_x_elem_pkey, bc_catalog_x_elem_pkey on bc_catalog_x_elem
(cost=0.00..837.80 rows=371 width=4)

So the
-> Seq Scan on bc_catalog_x_elem (cost=0.00..520.03
rows=455 width=4)

in (1) seems to be wrong...

I do a VACUUM ANALYZE regularly.

What's wrong? I don't want to turn off SEQ_SCAN, because many other
queries will suffer.

Dietrich

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message pgsql-bugs 2002-10-16 18:14:15 Bug #798: Data in table causes server to terminate with signal 11
Previous Message Tom Lane 2002-10-16 13:48:38 Re: multiple exception definition in pg_type.h -> error compiling postgres support in Qt with gcc v3.2 (SuSE 8.1)

Browse pgsql-novice by date

  From Date Subject
Next Message Tan ga 2002-10-16 14:56:15
Previous Message Mattia Boccia 2002-10-16 13:46:25 Re: information