Re: seqscan for 100 out of 3M rows, index present

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: Willy-Bas Loos <willybas(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: seqscan for 100 out of 3M rows, index present
Date: 2013-06-26 20:31:29
Message-ID: CAMkU=1xzMULy-Ag=h_XK12MhnDtX=qus5YuiO1UV_TQ-c=dL9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Jun 26, 2013 at 12:07 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>wrote:

> On Wed, Jun 26, 2013 at 9:45 AM, Willy-Bas Loos <willybas(at)gmail(dot)com>
> wrote:
> >
> > Aggregate (cost=60836.71..60836.72 rows=1 width=0) (actual
> > time=481.526..481.526 rows=1 loops=1)
> > -> Hash Join (cost=1296.42..60833.75 rows=1184 width=0) (actual
> > time=317.403..481.513 rows=17 loops=1)
> > Hash Cond: (d2.gid = g2.gid)
> > -> Seq Scan on d2 (cost=0.00..47872.54 rows=3107454 width=8)
> > (actual time=0.013..231.707 rows=3107454 loops=1)
>
> But this plan isn't retrieving just a few rows from d2, it's
> retreiving 3.1 Million rows.
>

But I think that that is the point. Why is it retrieving 3.1 million, when
it only needs 17?

Cheers,

Jeff

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Willy-Bas Loos 2013-06-26 20:36:10 Re: seqscan for 100 out of 3M rows, index present
Previous Message Willy-Bas Loos 2013-06-26 20:12:02 Re: seqscan for 100 out of 3M rows, index present