Re: bug in JOIN or COUNT or ... ?
От | The Hermit Hacker |
---|---|
Тема | Re: bug in JOIN or COUNT or ... ? |
Дата | |
Msg-id | Pine.BSF.4.33.0105122145100.629-100000@mobile.hub.org обсуждение исходный текст |
Ответ на | Re: bug in JOIN or COUNT or ... ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, 12 May 2001, Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > So why is it counting 12 more images then are actually found/exist: > > Hm. Could we see the EXPLAIN output for both of those? without count: NOTICE: QUERY PLAN: Unique (cost=8.66..8.67 rows=1 width=37) -> Sort (cost=8.66..8.66 rows=1 width=37) -> Nested Loop (cost=0.00..8.65rows=1 width=37) -> Nested Loop (cost=0.00..6.52 rows=1 width=33) -> NestedLoop (cost=0.00..4.26 rows=1 width=29) -> Index Scan using status_gid on status s (cost=0.00..2.23rows=1 width=12) -> Index Scan using images_gid on images i (cost=0.00..2.02 rows=1width=17) -> Index Scan using personal_data_gid on personal_data pd (cost=0.00..2.25 rows=1 width=4) -> Index Scan using relationship_wanted_gid on relationship_wanted rw (cost=0.00..2.11 rows=1 width=4) EXPLAIN with count: NOTICE: QUERY PLAN: Unique (cost=8.68..8.69 rows=1 width=37) -> Sort (cost=8.68..8.68 rows=1 width=37) -> Aggregate (cost=8.66..8.67rows=1 width=37) -> Group (cost=8.66..8.67 rows=1 width=37) -> Sort (cost=8.66..8.66rows=1 width=37) -> Nested Loop (cost=0.00..8.65 rows=1 width=37) -> Nested Loop (cost=0.00..6.52 rows=1 width=33) -> Nested Loop (cost=0.00..4.26 rows=1 width=29) -> Index Scan using status_gid on status s (cost=0.00..2.23 rows=1 width=12) -> Index Scan using images_gid on images i (cost=0.00..2.02 rows=1 width=17) -> Index Scan using personal_data_gid on personal_datapd (cost=0.00..2.25 rows=1 width=4) -> Index Scan using relationship_wanted_gidon relationship_wanted rw (cost=0.00..2.11 rows=1 width=4) EXPLAIN > > regards, tom lane > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
В списке pgsql-hackers по дате отправления: