On Fri, 15 Sep 2006 16:15:04 -0000 Andrew - Supernews <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
