Re: seqscan for 100 out of 3M rows, index present
| От | Jeff Janes |
|---|---|
| Тема | Re: seqscan for 100 out of 3M rows, index present |
| Дата | |
| Msg-id | CAMkU=1xzMULy-Ag=h_XK12MhnDtX=qus5YuiO1UV_TQ-c=dL9A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: seqscan for 100 out of 3M rows, index present (Scott Marlowe <scott.marlowe@gmail.com>) |
| Ответы |
Re: seqscan for 100 out of 3M rows, index present
|
| Список | pgsql-performance |
On Wed, Jun 26, 2013 at 12:07 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
On Wed, Jun 26, 2013 at 9:45 AM, Willy-Bas Loos <willybas@gmail.com> wrote:But this plan isn't retrieving just a few rows from d2, it's
>
> 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)
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
В списке pgsql-performance по дате отправления: