On Tue, Dec 27, 2011 at 12:29 PM, Jim Crate wrote:
> My question is why does it do a seq scan when it flattens this subquery into
> a JOIN? Is it because the emsg_messages table is around 1M rows? Are there
> some guidelines to when the planner will prefer not to use an available
> index? I
On Dec 27, 2011, at 1:12 PM, Tom Lane wrote:
> Jim Crate 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. Y
'
27.12.2011 20:13 пользователь "Tom Lane" написал:
>
> Jim Crate 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
=?UTF-8?Q?Ondrej_Ivani=C4=8D?= writes:
> The question is why the parameter f is not exposed as a GUC?
What would that accomplish that default_statistics_target doesn't?
(Other than being much harder to explain...)
regards, tom lane
--
Sent via pgsql-performance mailing
Hi,
On 28 December 2011 05:12, Tom Lane wrote:
> Possibly raising the stats target on emsg_messages would help.
In the function std_typanalyze() is this comment:
/*
* The following choice of minrows is based on the paper
* "Random sampling for histog
Jim Crate 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. You need to
see about getting that estimate to be off by
PostgreSQL 9.0.2
Mac OS X Server 10.6.8
Autovacuum is on, and I have a script that runs vacuum analyze verbose every
night along with the backup.
I have a situation where I'm experiencing a seq scan on a table with almost 3M
rows when my condition is based on a subquery. A google search turned
