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

Re: int8, primary key, seq scan

From: Jeff Amiel <jamiel(at)istreamimaging(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: int8, primary key, seq scan
Date: 2004-08-20 15:21:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
outside the function (from psql) I receive these results (which I guess 
are expected, because without casting, I assume it assumes an int4)

select  * from draft where check_id=43
and it results in a seq scan...
but if I :
select  * from draft where check_id=int8(43)
it results in an index scan using the primary key.


Tom Lane wrote:

>Jeff Amiel <jamiel(at)istreamimaging(dot)com> writes:
>>CREATE OR REPLACE FUNCTION public.insert_draft(int4,  numeric)
>>  RETURNS draft AS
>>  passed_customer ALIAS for $1;
>>  passed_amount ALIAS for $2;
>>  draftid int8;
>>  draftrow draft%rowtype;
>>insert into draft( amount, customer) values  (passed_amount, 
>>select into draftid currval(\'public.draft_check_id_seq\');
>>select into draftrow * from draft where check_id=int8(draftid);
>>return draftrow;
>>  LANGUAGE 'plpgsql' VOLATILE;
>Hmm.  I put this function into 7.4.5, minus the explicit cast to int8,
>and it worked just fine (I used a debugger to verify directly that the
>last SELECT was producing an indexscan plan).  I don't see anything in
>the CVS logs to suggest that there was a related bug fix between 7.4.2
>and 7.4.5.  So I'm baffled why it didn't work for you.  Ideas anyone?
>			regards, tom lane
>---------------------------(end of broadcast)---------------------------
>TIP 9: the planner will ignore your desire to choose an index scan if your
>      joining column's datatypes do not match

In response to

pgsql-general by date

Next:From: Manfred KoizarDate: 2004-08-20 15:23:12
Subject: Re: Postgres "invalid page header"
Previous:From: Bruce MomjianDate: 2004-08-20 15:12:40
Subject: Re: How to setup default value "0000-00-00" for "date"

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