|From:||David Fetter <david(at)fetter(dot)org>|
|To:||Tatsuo Ishii <ishii(at)postgresql(dot)org>|
|Cc:||Jim(dot)Nasby(at)BlueTreble(dot)com, alvherre(at)2ndquadrant(dot)com, michael(dot)banck(at)credativ(dot)de, tgl(at)sss(dot)pgh(dot)pa(dot)us, andrew(at)dunslane(dot)net, jaime(at)2ndquadrant(dot)com, andres(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, josh(at)agliodbs(dot)com, cktan(at)vitessedata(dot)com|
|Subject:||Re: Let's drop two obsolete features which are bear-traps for novices|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote:
> > The performance of our numeric vs Oracle's was a common complaint when
> > I was at EnterpriseDB (in 2007).
> > Perhaps numeric's performance could be greatly improved in cases where
> > the precision is low enough to map to an int/bigint. That would get us
> > closer to eliminating money as well as give other uses a big win. Of
> > course, how to do that and not break pg_upgrade is a huge question...
> Just out of curiosity, why is Oracle's NUMBER (I assume you are
> talking about this) so fast?
I suspect that what happens is that NUMBER is stored as a native type
(int2, int4, int8, int16) that depends on its size and then cast to
the next upward thing as needed, taking any performance hits at that
point. The documentation hints (38 decimal places) at a 128-bit
internal representation as the maximum. I don't know what happens
when you get past what 128 bits can represent.
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
|Next Message||Craig Ringer||2014-11-04 01:56:17||Re: [HACKERS] Pipelining executions to postgresql server|
|Previous Message||marc||2014-11-04 01:49:57||BUG #11867: Strange behaviour with composite types after resetting database tablespace|