index/join madness
От | Michael Richards |
---|---|
Тема | index/join madness |
Дата | |
Msg-id | 3B0B4776.0001A9.50190@frodo.searchcanada.ca обсуждение исходный текст |
Ответы |
Re: index/join madness
(David Olbersen <dave@slickness.org>)
Re: index/join madness (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-sql |
Ok, I've built the most insane query ever. It joins 11 tables, most of which are the same table, just extracting different values. Here is the query plan: Nested Loop (cost=0.00..5011.89 rows=1 width=156) -> Nested Loop (cost=0.00..4191.82 rows=1 width=140) -> NestedLoop (cost=0.00..4189.79 rows=1 width=112) -> Nested Loop (cost=0.00..4188.58 rows=1 width=104) -> Nested Loop (cost=0.00..4186.55 rows=1 width=88) -> Nested Loop (cost=0.00..3366.48 rows=1 width=72) -> Nested Loop (cost=0.00..2546.41 rows=1 width=68) -> Nested Loop (cost=0.00..1726.34 rows=1 width=52) -> Nested Loop (cost=0.00..906.27 rows=1 width=32) -> Seq Scan on formdata f6 (cost=0.00..904.16 rows=1 width=4) -> Index Scan using users_pkey on users u (cost=0.00..2.02 rows=1 width=28) SubPlan -> Seq Scan on sentletters (cost=0.00..0.00 rows=1 width=4) -> Seq Scan on formdata f5 (cost=0.00..818.42 rows=131 width=20) -> Seq Scan on formdata f2 (cost=0.00..818.42 rows=131 width=16) -> Seq Scan on formdata f1 (cost=0.00..818.42 rows=131 width=4) -> Seq Scan on formdata f3 (cost=0.00..818.42 rows=131 width=16) -> Index Scan using formmvl_pkey on formmvl m (cost=0.00..2.02 rows=1 width=16) -> Seq Scan on relations r (cost=0.00..1.12 rows=7 width=8) -> Index Scan using users_pkey on users u2 (cost=0.00..2.02 rows=1 width=28) -> Seq Scan on formdata f4 (cost=0.00..818.42 rows=131 width=16) If anyone has a screen wide enough to see this, you will see that the majority of the time is spent doing sequential scans on the formdata table. This table needs formid, fieldid and userid to find the value I'm looking for. It has one index defined on: Index "formdata_pkey"Attribute | Type -----------+---------formid | integeroccid | integeruserid | integerfieldid | integer unique btree (primary key) In my case I'm ignoring occid since it's always 1 for these values. Is there any way I can coerce this into using a multifield index? My joins generally look like: JOIN formdata AS f2 ON (u.id=f2.userid AND f2.formid=1 AND f2.fieldid=2) I'm a little curious as to why it's not using the primary key... Finally, I'm planning on moving this to 7.2 and converting all the joins to use outer joins. Will there be a significant penalty in performance running outer joins? -Michael _________________________________________________________________ http://fastmail.ca/ - Fast Free Web Email for Canadians
В списке pgsql-sql по дате отправления: