Re: [PERFORM] Planner choosing NestedLoop, although it is slower...

2011-07-14 Thread Clem Dickey
On 07/12/2011 11:11 AM, Mario Splivalo wrote: Hi, all. I have a query, looking like this: SELECT pub_date FROM tubesite_object INNER JOIN tubesite_image ON tubesite_image.object_ptr_id = tubesite_object.id WHERE tubesite_object.site_id = 8 AND tubesite_object.pub_date < E'2011-07-12 13:25:00' OR

Re: [PERFORM] Planner choosing NestedLoop, although it is slower...

2011-07-12 Thread Mario Splivalo
On 07/13/2011 02:53 AM, Mario Splivalo wrote: On 07/13/2011 12:39 AM, Tom Lane wrote: Mario Splivalo writes: On 07/12/2011 10:04 PM, Tom Lane wrote: What you need to look into is why the estimated join size is 9400 rows when the actual join size is zero. Are both tables ANALYZEd? Are you inten

Re: [PERFORM] Planner choosing NestedLoop, although it is slower...

2011-07-12 Thread Mario Splivalo
On 07/13/2011 12:39 AM, Tom Lane wrote: Mario Splivalo writes: On 07/12/2011 10:04 PM, Tom Lane wrote: What you need to look into is why the estimated join size is 9400 rows when the actual join size is zero. Are both tables ANALYZEd? Are you intentionally selecting rows that have no join pa

Re: [PERFORM] Planner choosing NestedLoop, although it is slower...

2011-07-12 Thread Mario Splivalo
On 07/13/2011 12:39 AM, Tom Lane wrote: Mario Splivalo writes: On 07/12/2011 10:04 PM, Tom Lane wrote: What you need to look into is why the estimated join size is 9400 rows when the actual join size is zero. Are both tables ANALYZEd? Are you intentionally selecting rows that have no join pa

Re: [PERFORM] Planner choosing NestedLoop, although it is slower...

2011-07-12 Thread Tom Lane
Mario Splivalo writes: > On 07/12/2011 10:04 PM, Tom Lane wrote: >> What you need to look into is why the estimated join size is 9400 rows >> when the actual join size is zero. Are both tables ANALYZEd? Are you >> intentionally selecting rows that have no join partners? > Yes, both tables have

Re: [PERFORM] Planner choosing NestedLoop, although it is slower...

2011-07-12 Thread Mario Splivalo
On 07/12/2011 10:04 PM, Tom Lane wrote: Mario Splivalo writes: Limit (cost=0.00..415.91 rows=21 width=8) (actual time=11263.089..11263.089 rows=0 loops=1) -> Nested Loop (cost=0.00..186249.55 rows=9404 width=8) (actual time=11263.087..11263.087 rows=0 loops=1) Why is planner usin

Re: [PERFORM] Planner choosing NestedLoop, although it is slower...

2011-07-12 Thread Tom Lane
Mario Splivalo writes: > Limit (cost=0.00..415.91 rows=21 width=8) (actual > time=11263.089..11263.089 rows=0 loops=1) > -> Nested Loop (cost=0.00..186249.55 rows=9404 width=8) (actual > time=11263.087..11263.087 rows=0 loops=1) > Why is planner using NestedLoops, Because it thinks th

[PERFORM] Planner choosing NestedLoop, although it is slower...

2011-07-12 Thread Mario Splivalo
Hi, all. I have a query, looking like this: SELECT pub_date FROM tubesite_object INNER JOIN tubesite_image ON tubesite_image.object_ptr_id = tubesite_object.id WHERE tubesite_object.site_id = 8 AND tubesite_object.pub_date < E'2011-07-12 13: