Re: planner or statistical bug on 8.5

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Matteo Beccati <php(at)beccati(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: planner or statistical bug on 8.5
Date: 2010-01-12 08:08:25
Message-ID: 162867791001120008q3a986d92p75a55b128577440f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/1/12 Matteo Beccati <php(at)beccati(dot)com>:
> Il 12/01/2010 08:55, Pavel Stehule ha scritto:
>>
>> I checked query and I was surprised with very strange plan:
>>
>> postgres=# explain select  a, b from a,b,c;
>>                               QUERY PLAN
>> -----------------------------------------------------------------------
>>  Nested Loop  (cost=0.00..276595350.00 rows=13824000000 width=8)
>>    ->   Nested Loop  (cost=0.00..115292.00 rows=5760000 width=8)
>>          ->   Seq Scan on a  (cost=0.00..34.00 rows=2400 width=4)
>>          ->   Materialize  (cost=0.00..82.00 rows=2400 width=4)
>>                ->   Seq Scan on b  (cost=0.00..34.00 rows=2400 width=4)
>>    ->   Materialize  (cost=0.00..82.00 rows=2400 width=0)
>>          ->   Seq Scan on c  (cost=0.00..34.00 rows=2400 width=0)
>> (7 rows)
>
> It doesn't surprise me. Tables are empty, thus get a default non-0 row
> estimate, which happens to be 2400:
>

I though so default estimate is used only when table wasn't analysed.
But you have a true. I am verifying it on 8.3 and the behave is same.

so all is ok.

Regards
Pavel Stehule

> test=# create table a (a int);
> CREATE TABLE
> test=# ANALYZE a;
> ANALYZE
> test=# EXPLAIN SELECT * from a;
>                     QUERY PLAN
> -----------------------------------------------------
>  Seq Scan on a  (cost=0.00..14.80 rows=2400 width=4)
> (1 row)
>
>
> That said, 2400^3 (cross join of 3 tables) == 13824000000
>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-01-12 08:40:03 Re: Hot Standy introduced problem with query cancel behavior
Previous Message Greg Smith 2010-01-12 08:04:35 Re: Streaming replication status