On Monday 05 January 2004 17:48, David Teran wrote:
> > 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
> 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