On Monday 05 January 2004 17:48, David Teran wrote:
> Hi,
> > The performance will likely to be the same. Its just that integer
> > happens to
> > be default integer type and hence it does not need an explicit
> > typecast. ( I
> > don't remember exactly which integer is default but it is either of
> > int2,int4
> > and int8...:-))
> The docs say int4 is much faster than int8, but i will check this.

Well yes. That is correct as well. 

What I (really) meant to say that an index scan to pick few in4 tuples 
wouldn't be hell much faster than an index scan to pick same number of tuples 
with int8 definition. 

The initial boost you got from converting to index scan, would be probably 
best you can beat out of it..

Of course if you are scanning a few million of them sequentially, then it is 
different story.

> This is my bigger problem: i am using EOF (OR mapping tool) which frees
> me more or less form writing a lot of SQL. If i need to typecast to use
> an index then i have to see how to do this with this framework.

Well, you can direct your queries to a function rather than table, that would 
cast the argument appropriately and select. Postgresql support function 
overloading as well, in case you need different types of arguments with same 

Or you can write an instead rule on server side which will perform casting 
before touching the table.

I am not sure of exact details it would take to make it work, but it should 
work, at least in theory. That way you can preserve the efforts invested in 
the mapping tool. 

Of course, converting everything to integer might be a simpler option after 


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to