Skip site navigation (1) Skip section navigation (2)

Re: Avoiding a seq scan on a table.

From: "Sean Davis" <sdavis2(at)mail(dot)nih(dot)gov>
To: LWATCDR <lwatcdr(at)gmail(dot)com>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: Avoiding a seq scan on a table.
Date: 2008-01-14 17:25:43
Message-ID: 264855a00801140925x3208fa30x98ad59547a8679cc@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-novice
On Jan 14, 2008 12:14 PM, LWATCDR <lwatcdr(at)gmail(dot)com> 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))


The Postgres planner will choose what it thinks is the fastest plan.  In
this case, your table has only 1 row (?), so sequential scan will be
fastest.  You will want to load data into your table before doing
benchmarking.

Sean

In response to

pgsql-novice by date

Next:From: Brian HurtDate: 2008-01-14 17:28:09
Subject: Re: Avoiding a seq scan on a table.
Previous:From: Daniel T. StaalDate: 2008-01-14 17:22:57
Subject: Re: Avoiding a seq scan on a table.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group