| From: | Mario Splivalo <mario(dot)splivalo(at)megafon(dot)hr> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Planner choosing NestedLoop, although it is slower... |
| Date: | 2011-07-12 23:57:06 |
| Message-ID: | 4E1CDF52.4020208@megafon.hr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 07/13/2011 12:39 AM, Tom Lane wrote:
> Mario Splivalo<mario(dot)splivalo(at)megafon(dot)hr> 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 been ANALYZEd. What do you mean, intentilnaly
>> selecting rows taht have no join partners?
>
> I'm wondering why the actual join size is zero. That seems like a
> rather unexpected case for a query like this.
It is true that this particular query returns 0 rows. But it's created
by django, and I can't do much to alter it.
Mario
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2011-07-13 00:35:54 | Re: UPDATEDs slowing SELECTs in a fully cached database |
| Previous Message | lars | 2011-07-12 23:15:12 | Re: UPDATEDs slowing SELECTs in a fully cached database |