Re: [HACKERS] wrong query plan in 7.1beta3 - Mailing list pgsql-sql

From Peter Eisentraut
Subject Re: [HACKERS] wrong query plan in 7.1beta3
Date
Msg-id Pine.LNX.4.30.0101271543400.1492-100000@peter.localdomain
Whole thread Raw
In response to wrong query plan in 7.1beta3  (Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu>)
Responses Re: [HACKERS] wrong query plan in 7.1beta3  (Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu>)
List pgsql-sql
Kovacs Zoltan writes:

> There seems to be an optimizer problem in 7.1beta3. The query you can see
> below worked fast in 7.0.2 but in 7.1beta3 is rather slow. The problem is
> that an 'index scan' has been changed to a 'seq scan'. Details:

> Subquery Scan sd_user_grant  (cost=38.68..38.85 rows=1 width=61)
>   ->  Aggregate  (cost=38.68..38.85 rows=1 width=61)
>         ->  Group  (cost=38.68..38.73 rows=10 width=61)
>               ->  Sort  (cost=38.68..38.68 rows=10 width=61)
>                     ->  Nested Loop  (cost=0.00..38.51 rows=10 width=61)
>                           ->  Seq Scan on pg_shadow  (cost=0.00..1.01 rows=1 width=32)
>                           ->  Seq Scan on sd_grant  (cost=0.00..20.00 rows=1000 width=29)

You haven't VACUUM ANALYZE'd the sd_grant table.  Therefore the row
estimate is way off (1000 vs 6) and thus a sequential scan is (correctly)
thought to be faster.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-sql by date:

Previous
From: Kovacs Zoltan
Date:
Subject: wrong query plan in 7.1beta3
Next
From: Kovacs Zoltan
Date:
Subject: Re: [HACKERS] wrong query plan in 7.1beta3