Skip site navigation (1) Skip section navigation (2)

Re: Subquery flattening causing sequential scan

From: Віталій Тимчишин <tivv00(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org, Jim Crate <jimcfl(at)gmail(dot)com>
Subject: Re: Subquery flattening causing sequential scan
Date: 2011-12-28 08:30:59
Message-ID: CABWW-d2s=7A1SZz85vW_SYvLvWO2U54xc7DxwC_bo=saCitNLQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
'
27.12.2011 20:13 пользователь "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> написал:
>
> Jim Crate <jimcfl(at)gmail(dot)com> writes:
> > My question is why does it do a seq scan when it flattens this
> > subquery into a JOIN?
>
> Because it thinks there will be 3783 rows out of the msg scan, which if
> true would make your desired nestloop join a serious loser.

But second plan is evaluated cheapier by analyze. I thought this should
make it being used unless it is not evaluated. Can it be collapse limit
problem or like?

In response to

pgsql-performance by date

Next:From: Matteo BeccatiDate: 2011-12-28 09:57:10
Subject: Re: PostgreSQL 9.0.4 blocking in lseek?
Previous:From: Tom LaneDate: 2011-12-28 00:28:37
Subject: Re: Subquery flattening causing sequential scan

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group