On Fri, 15 Sep 2006 16:15:04 -0000
Andrew - Supernews <andrew+nonews@supernews.com> wrote:
> On 2006-09-15, "D'Arcy J.M. Cain" <darcy@druid.net> wrote:
> >> Seems? Have you benchmarked it?
> >
> > Not rigourously but a few "ANALYZE EXPLAIN" statements bear out this
> > observation.
>
> The overhead of EXPLAIN ANALYZE is so large that it completely swamps any
> real difference.
Hence my "not rigourously" comment.
> First measure the benchmark overhead:
>
> select null::integer from generate_series(1,1000) s1,
> generate_series(1,1000) s2;
Time: 870.531 ms
> Since output functions are strict, this does not call int4out at all, so
> this measures the time taken to generate the million rows, output and discard
> them.
>
> Then do the real tests:
>
> select 0::integer from generate_series(1,1000) s1,
> generate_series(1,1000) s2;
Time: 1410.690 ms
> This calls int4out(0) a million times. (the input function is only called
> once since it is a constant, and therefore handled during planning)
>
> select 0::numeric from generate_series(1,1000) s1,
> generate_series(1,1000) s2;
Time: 1256.539 ms
Selecting "'0'::money" gives:
Time: 1487.757 ms
Bigint gives:
Time: 1450.405 ms
The extra processing over int and bigint is probably due to locale
formatting. That's partially why I was wondering if the basic type
should be doing that as opposed to doing it in app code. Also, I
wonder if some of the techniques in numeric could be applied here. I
haven't looked carefully at the numeric output code yet.
In any case, I/O speed is probably not that important with this type.
Internal calculations, in my experience, are much more critical.
--
D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.