Irrelevant of the number of rows, PG should read 8 tuples and return.
There may be alot of deleted tupples at the head of that table.
When was the last time you vaccumed?
"Lufkin, Brad" wrote:
>
> 30 million rows....
>
> -----Original Message-----
> From: scott.marlowe [mailto:scott.marlowe@ihs.com]
> Sent: Wednesday, August 13, 2003 4:39 PM
> To: Lufkin, Brad
> Cc: 'psql'
> Subject: Re: [JDBC] Query Time
>
> How many rows in that table? 90 seconds is a long time for a select to
> take, period, with or without a limit.
>
> On Wed, 13 Aug 2003, Lufkin, Brad wrote:
>
> > Thanks for the info. Still, I'm surprised that a limited query would take
> 90
> > seconds.
> >
> > -----Original Message-----
> > From: scott.marlowe [mailto:scott.marlowe@ihs.com]
> > Sent: Wednesday, August 13, 2003 4:20 PM
> > To: Lufkin, Brad
> > Cc: 'psql'
> > Subject: Re: [JDBC] Query Time
> >
> >
> > On Wed, 13 Aug 2003, Lufkin, Brad wrote:
> >
> > > I'm running the following query:
> > >
> > > SELECT * FROM someTable LIMIT 20
> > >
> > > I turned on explain analyze (tip #8!) and was told that the query plan
> was
> > > sequential (no surprise there) with an estimated cost of between 0.00
> and
> > > 1.07. Surprisingly, the actual time was around 90000 msec (or
> > one-and-a-half
> > > minutes). What's going on?
> >
> > costs are estimated as a percentage of a cost of a single page access in
> > sequential mode. I.e. a single sequential page access is assumed to cost
> > 1.0, and everything is relative to that. The cost numbers do NOT
> > translate directly into any time unit.
> >
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
