Re: How does Index Scan get used

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oliver Elphick <olly(at)lfix(dot)co(dot)uk>
Cc: "Samuel J(dot) Sutjiono" <ssutjiono(at)wc-group(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: How does Index Scan get used
Date: 2002-02-23 00:11:47
Message-ID: 21701.1014423107@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Oliver Elphick <olly(at)lfix(dot)co(dot)uk> writes:
> On Fri, 2002-02-22 at 18:08, Oliver Elphick wrote:
>> PostgreSQL thinks there are only 10 rows in the table. Therefore it
>> will not choose an index scan because for so few rows it is bound to be
>> more expensive than a sequential scan.

> But then I saw Tom's mail saying that it does use the index. How is
> that? Surely these few values would all be brought in in one single
> disk read?

Well, there are two different issues here. One is whether the query
*can* use the index --- that depends on your locale, as I pointed out,
and also on the details of the LIKE or regex pattern being used, as
Frank Bax points out nearby. The other issue is whether the planner
*will choose to* use the index, when it has a choice.

Oliver is quite correct that the planner would not choose to use the
index on such a small table --- if it knows the table is small. But
in these dummy examples that we're discussing, we just created the table
and index and then put a few values in (the order is important BTW),
and we never vacuumed. In this scenario the table size estimates in
pg_class have never been changed from the initial dummy values that
CREATE TABLE puts in --- and those dummy values are deliberately set
large enough to allow index scans. (10 pages / 1000 rows, IIRC.)
We don't initialize the size estimates to zero, because if we did,
the planner would make totally foolish choices for never-vacuumed
tables ... which could actually contain lots of data.

VACUUM the test table, and it'll stop using the index, unless you put a
lot more test data in than we've used in these examples.

Oh BTW: the "10 rows" Oliver was wondering about are not the number of
rows the planner thinks are in the table; they're the estimated number
of result rows. Since there's no VACUUM ANALYZE stats available either,
this is just a default selectivity estimate for the match clause (0.01)
times the initial dummy reltuples value (1000). Not much content in it
at all, eh?

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Mark kirkwood 2002-02-23 00:29:56 Re: [SQL] Transient Disk Usage Higher In 7.2 ?
Previous Message Mark kirkwood 2002-02-22 23:47:39 Re: comparision chart