Re: Avoiding a seq scan on a table.

Поиск
Список
Период
Сортировка
От LWATCDR
Тема Re: Avoiding a seq scan on a table.
Дата
Msg-id 8c38cea40801140935y4e39a510vff58bde219693356@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Avoiding a seq scan on a table.  ("Daniel T. Staal" <DStaal@usa.net>)
Ответы Re: Avoiding a seq scan on a table.  ("Daniel T. Staal" <DStaal@usa.net>)
Список pgsql-novice
that is very odd since that table has 141 records in it.

here is a different query that I ran.
SELECT COUNT(*) FROM rma where terminatedate is NULL;
This returns a value of 254 for the count but this is what I get from explain.

Aggregate  (cost=219.77..219.78 rows=1 width=0)
  ->  Seq Scan on rma  (cost=0.00..219.11 rows=264 width=0)
        Filter: (terminatedate IS NULL)
This says that rows =1 but returns 254 rows of data?
The table contains over 7000 rows.


On Jan 14, 2008 12:22 PM, Daniel T. Staal <DStaal@usa.net> wrote:
>
> On Mon, January 14, 2008 12:14 pm, LWATCDR wrote:
> > Really? From what I have done in writing my own code I have found
> > hashing to be faster than a btree but then when I wrote my own hashing
> > it was a specific type of key.
> > Anyway I put in the tree indexes and I am still getting a seq scan.
> >
> > Aggregate  (cost=12.12..12.13 rows=1 width=0)
> >   ->  Result  (cost=0.00..12.12 rows=1 width=0)
> >         One-Time Filter: NULL::boolean
> >         ->  Seq Scan on issuetracking  (cost=0.00..12.12 rows=1 width=0)
> >               Filter: (((issue_target)::text = 'david'::text) OR
> > ((manager)::text = 'david'::text))
>
> Based on that cost, a sequence scan is probably the fastest yet: It's such
> a small dataset that fetching the index and working with it before going
> back and fetching the data is just overkill.
>
> When you add a few dozen more rows or so, it'll switch to using the index.
>
> Daniel T. Staal
>
> ---------------------------------------------------------------
> This email copyright the author.  Unless otherwise noted, you
> are expressly allowed to retransmit, quote, or otherwise use
> the contents for non-commercial purposes.  This copyright will
> expire 5 years after the author's death, or in 30 years,
> whichever is longer, unless such a period is in excess of
> local copyright law.
> ---------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

В списке pgsql-novice по дате отправления:

Предыдущее
От: Brian Hurt
Дата:
Сообщение: Re: Avoiding a seq scan on a table.
Следующее
От: "Daniel T. Staal"
Дата:
Сообщение: Re: Avoiding a seq scan on a table.