On Sun, Nov 14, 2010 at 1:25 PM, Robert Haas <robertmh...@gmail.com> wrote: > Like Tom, I'm not sure this is really a type-system problem. This > sounds like a complaint that operations on "numeric" are much slower > than operations on "int4" and "int8", even for values that could be > represented by either type. I think that's a valid complaint, but I > don't see how changing the type system would help. I think what you'd > need to is optimize the existing numeric type, or provide a new > numeric-ish type with optimizations for dealing with > small-to-medium-sized integers.
There are other ways one might be able to attack the performance part of the problem, but consider the loss of information about the type from int(2|4|8) to numeric when composing a series of sums: we know the value produced fits the abstract notion of an Integer, but we lose that information. The same could be said of SUM(x::numeric(1000,0)) yielding an unrestricted numeric, rather than one of scale 0. Not only is there more information available to the user, but the optimizer should be able to benefit from that information as well. However, for an arbitrary user-defined operator to take advantage it would seem to me that there needs to be a hook where some reasoning can take place over its input types and subsequently determine the return prototype at that call site. I am not trying to suggest that there is no way that one could attack the details around SUM I have mentioned without changing the type system, only that they are limitations I encountered and worked around where a more powerful type system came to mind as an avenue for a simpler/more proper solution. fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
