| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | SZŰCS Gábor <surrano(at)mailbox(dot)hu> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Query Plan far worse in 7.3.2 than 7.2.1 |
| Date: | 2003-04-29 23:05:53 |
| Message-ID: | 18324.1051657553@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance pgsql-sql |
"=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <surrano(at)mailbox(dot)hu> writes:
> ---------------------------- 7.2.1 PLAN ---------------------------------
> -> Seq Scan on valuta (cost=0.00..1.06 rows=6 width=4) (actual time=0.02..0.11 rows=6 loops=2)
>
> ---------------------------- 7.3.2 PLAN ---------------------------------
> -> Seq Scan on valuta (cost=0.00..20.00 rows=1000 width=4) (actual time=0.02..0.06 rows=6 loops=2)
Ah, there's the problem. You never vacuumed or analyzed "valuta", so
the 7.3 planner didn't know it had only six rows, and chose a plan that
was more appropriate for a larger table. The thousand-row estimate is
the tipoff, because that's the default assumption when there are no
stats.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2003-04-30 06:04:25 | Why LIMIT after scanning the table? |
| Previous Message | SZŰCS Gábor | 2003-04-29 16:03:48 | Re: Query Plan far worse in 7.3.2 than 7.2.1 |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergey Holod | 2003-04-29 23:18:08 | Re: Making "SECURITY DEFINER" procedures.. |
| Previous Message | Stephan Szabo | 2003-04-29 22:10:45 | Re: Making "SECURITY DEFINER" procedures.. |