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

Re: Sequential Scan Index Bug

From: "Gabriel Weinberg" <yegg(at)alum(dot)mit(dot)edu>
To: "'Bruno Wolff III'" <bruno(at)wolff(dot)to>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Sequential Scan Index Bug
Date: 2004-04-07 13:42:14
Message-ID: 000a01c41ca6$233b8a70$0900a8c0@yegg (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Yes, I thought I had done that, but now that I figured out what was going
on, I did it for all cases.  So it is no longer occurring for me, but it
still seems like a bug in PostgreSQL.  I would expect it to throw an error
immediately, instead of scanning the table for a value of a different type.
In my case, the table is huge, so it really put a hamper on the system.


Gabriel Weinberg

-----Original Message-----
From: Bruno Wolff III [mailto:bruno(at)wolff(dot)to] 
Sent: Wednesday, April 07, 2004 1:38 AM
To: Gabriel Weinberg
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Sequential Scan Index Bug

On Sat, Apr 03, 2004 at 13:51:56 -0500,
  Gabriel Weinberg <yegg(at)alum(dot)mit(dot)edu> wrote:
> I have a table with an integer column with about 10M rows in it.
> This column has an index (btree).
> When I try to select a row using this column with an integer, e.g. 
> select * from table where id=4, it always uses the index.  However, if 
> I select try to select a row using this column with a decimal, e.g. 
> select * from table where id=4.343, it skips the index entirely and 
> does a sequential scan of the table.
> I am using v7.4.2 on Freebsd 4.9.

Depending on what you want to do, you probably either want to cast the value
to an int explicitly or combine that with a test (using a stable
function) to make sure the number is actually an integer.

In response to


pgsql-bugs by date

Next:From: Stephan SzaboDate: 2004-04-07 15:35:02
Subject: Re: Sequential Scan Index Bug
Previous:From: PostgreSQL Bugs ListDate: 2004-04-07 06:31:47
Subject: BUG #1129: select query returns multiple results for a japanese characters

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