| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Sean Leach <sleach(at)wiggum(dot)com> | 
| Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | Re: Weird issue with planner choosing seq scan | 
| Date: | 2008-02-24 17:50:31 | 
| Message-ID: | 5289.1203875431@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
Sean Leach <sleach(at)wiggum(dot)com> writes:
> I have a table, that in production, currently has a little over 3  
> million records in production.  In development, the same table has  
> about 10 million records (we have cleaned production a few weeks  
> ago).
You mean the other way around, to judge by the rowcounts from EXPLAIN.
>           ->  Index Scan using u_counts_i2 on u_counts c   
> (cost=0.00..53.53 rows=1082 width=4) (actual time=0.277..1224.582  
> rows=392173 loops=1)
I kinda think the devel system wouldn't be using an indexscan either
if it had up-to-date ANALYZE statistics.  But even with the 1082 row
estimate that seems a remarkably low cost estimate.  Have you been
playing games with random_page_cost?  Maybe you forgot to duplicate the
devel system's cost parameters onto the production system?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sean Leach | 2008-02-24 18:41:26 | Re: Weird issue with planner choosing seq scan | 
| Previous Message | Sean Leach | 2008-02-24 15:40:54 | Weird issue with planner choosing seq scan |