Re: again on index usage

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Daniel Kalchev <daniel(at)digsys(dot)bg>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: again on index usage
Date: 2002-01-09 09:45:22
Message-ID: 3C3C1132.E51307CF@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Kalchev wrote:
>
> >>>Tom Lane said:
> > Daniel Kalchev <daniel(at)digsys(dot)bg> writes:
> > > Same result (sorry, should have included this originally):
> >
> > >>> If you say "set enable_seqscan to off", does that change the plan?
> >
> > > Aggregate (cost=100359.71..100359.71 rows=1 width=8)
> > > -> Index Scan using iplog_gate200112_ipdate_idx on iplog_gate200112
> > > (cost=0.00..100217.52 rows=56873 width=8)
> >
> > So, what we've got here is a difference of opinion: the planner thinks
> > that the seqscan will be faster. How many rows are actually selected
> > by this WHERE clause? How long does each plan actually take?
> >
> > regards, tom lane
>
> 3-5 minutes with sequential scan; 10-15 sec with index scan. The query returns
> 4062 rows. Out of ca 1700000 rows.
>
> With only the datetime constraints (which relates to the index), the number of
> rows is 51764.

The planner estimates 56873 rows. It seems not that bad.
A plausible reason is your table is nearly clustered
as to ipdate.

regards,
Hiroshi Inoue

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2002-01-09 10:02:42 Re: 7.2 is slow?
Previous Message Zeugswetter Andreas SB SD 2002-01-09 09:14:36 Re: ECPG: include sqlca