Re: Weird issue with planner choosing seq scan

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-performance by date

  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