Re: [SQL] Index selection on a large table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Michael Richards" <michael(at)fastmail(dot)ca>
Cc: pgsql-sql(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [SQL] Index selection on a large table
Date: 2000-07-25 23:30:39
Message-ID: 8873.964567839@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-sql

"Michael Richards" <michael(at)fastmail(dot)ca> writes:
> The following query yeilds the questionable query plan:

> explain select * from logins where ip='38.30.141.44';
> NOTICE: QUERY PLAN:
> Seq Scan on logins (cost=0.00..25248.51 rows=11602 width=48)

If there really were 11602 matching rows, the seq scan likely would be
the way to go. So the issue here is poor selectivity estimation.

You said you did a VACUUM, but you didn't mention if you'd ever done
a VACUUM ANALYZE. That looks to me like it's using the default 1%
selectivity estimate, which is what you'd get if you hadn't ever
done an ANALYZE.

If you have done one, what do you get from

select attname,attdisbursion,s.*
from pg_statistic s, pg_attribute a, pg_class c
where starelid = c.oid and attrelid = c.oid and staattnum = attnum
and relname = 'logins';

?

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andriy I Pilipenko 2000-07-26 06:24:49 Index selection bug
Previous Message Michael Richards 2000-07-25 23:03:38 Index selection on a large table

Browse pgsql-sql by date

  From Date Subject
Next Message Bernie Huang 2000-07-25 23:34:19 Change attribute of a column
Previous Message Tom Lane 2000-07-25 23:05:27 Re: pg_dump