Re: why am I getting a seq scan on this query?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Mark Harrison <mh(at)pixar(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: why am I getting a seq scan on this query?
Date: 2006-01-06 21:43:36
Message-ID: 23030.1136583816@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Someone might have a better idea but my guess is that PG things the
> seq_scan would be faster.

That's what it thinks, and it might be right. This query is fetching 2%
of the table, which is near the crossover point where a seqscan is
faster, assuming that the rows aren't very wide and the target rows are
fairly randomly distributed through the table's pages.

> You could try decreasing your random_page_cost.

First thing to do is force the plan choice (set enable_seqscan = off)
and see what timings you actually get each way. If the planner really
is guessing materially wrong, then adjusting the cost parameters is
called for. Don't set them on the basis of a single test case though...

BTW, the bitmap indexscan method available in PG 8.1 can do a lot better
than plain indexscan for scenarios like this, so updating to 8.1 might
be a good answer too.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Reid Thompson 2006-01-06 21:50:16 Flagging and/or Cleansing/Correcting bad telephone number data
Previous Message Scott Ribe 2006-01-06 21:28:15 Re: Reordering columns in a table