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.
Advertising
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 name. 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 all..:-) Shridhar ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
