On Sat, Dec 8, 2012 at 5:19 AM, Guillaume Smet wrote:
> Hi Jeff,
>
> On Sat, Dec 8, 2012 at 3:32 AM, Jeff Janes wrote:
>> If those estimates are better, it probably means that your filter
>> condition is picking a part of the "el JOIN l" that has much different
>> selectivity to r than the full s
(cough cough, missed the Reply to all button)
Hi Jeff,
On Sat, Dec 8, 2012 at 3:32 AM, Jeff Janes wrote:
> If those estimates are better, it probably means that your filter
> condition is picking a part of the "el JOIN l" that has much different
> selectivity to r than the full set does, and Pos
Jeff Janes writes:
> The trivial answer to "why" is that it thinks that the vast majority
> of the 33914 rows from the hash join will find no partners in r, but
> in fact each has about 10 partner in r. Why does it think that?
I'm wondering if maybe the vast majority of the rows indeed have no j
On Wed, Dec 5, 2012 at 11:39 AM, Guillaume Smet
wrote:
> Hi,
>
> I'm struggling with a query for some time and the major problem of the
> query is that the statistics are way wrong on a particular operation:
> -> Nested Loop (cost=3177.72..19172.84 rows=*2* width=112) (actual
> time=139.221..60
Hi,
I'm struggling with a query for some time and the major problem of the
query is that the statistics are way wrong on a particular operation:
-> Nested Loop (cost=3177.72..19172.84 rows=*2* width=112) (actual
time=139.221..603.929 rows=*355331* loops=1)
Join Filter: (l.location_id = r.l
