Bugs in bigint indexes

From: "Gustavo Scotti" <gscotti(at)axur(dot)com(dot)br>
To: <pgsql-bugs(at)postgresql(dot)org>
Subject: Bugs in bigint indexes
Date: 2003-12-17 19:56:51
Message-ID: 009401c3c4d7$ebfee870$1500a8c0@pae.br.axur.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

<http://www.axur.com.br/images/axur_animado.gif>
_____

Dear developers,

I almost got nuts those two days I'm stuck with this issue...
Let's get straight to the point. I'm using a small portion of my actual
table, but this is enough.

CREATE SEQUENCE it_seq;
CREATE TABLE it_test (
id bigint not null primary key default
nextval('public.it_test_id_seq'::text)
);

explain SELECT id FROM it_test WHERE id=123;
Seq Scan on it_test (cost=0.0..22.50 rows=2 width=8)
Filter: (id=123)
(2 rows)

when the key is bigint, it ignores any kind of index scan, it always use
Seq scan. Why?

Changed the bigint for a regular int (I need a 64bit identificator for
my primary key) and it started working... see:
Index Scan using it_test_pkey on it_test (cost=0.00..4.82 rows=2
width=4)
Index Cond: (id=32)
(2 rows)

That's what I wanted to happen when a bigint fields are used.

I suspected that after some 100k rows the queries where slower, and
slower, and slower.

Please help me.. for the fix I'm using 32bits integer, but I believe the
rows will get over 2 billion registers.

BTW: Tryed postgresql 7.3.4 7.3.5, and 7.4. None worked.

Thank you very much, I would really apreciate a feedback.

Kindly,

Gustavo Scotti
Axur Information Security
Porto Alegre - RS - Brasil
Tel.: +55 (51) 3222 2874
www.axur.com.br <http://www.axur.com.br/>

As informações existentes nessa mensagem e no(s) arquivo(s) anexado(s)
são para uso restrito, sendo seu sigilo protegido por lei. Caso não seja
destinatário, saiba que leitura, divulgação ou cópia são proibidas.
Favor apagar as informações e notificar o remetente. O uso impróprio
será tratado conforme as normas da empresa e a legislação em vigor.
Agradecemos sua colaboração.

The information mentioned in this message and in the archives attached
are of restricted use, and its privacy is protected by law. If you are
not the addressee, be aware that reading, disclosure or copy are
forbidden. Please delete this information and notify the sender.
Inappropriate use will be tracted according to company's rules and valid
laws.
Thank you for your cooperation.


Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mark Pether 2003-12-17 20:14:31 ecpg c++ scope operator lost
Previous Message Tom Lane 2003-12-17 19:02:49 Re: SELECT FOR UPDATE differs inside and outside a pl/pgsql function (7.4)