Re: Let's drop two obsolete features which are bear-traps for novices

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
Date: 2014-11-04 01:52:41
Message-ID: 20141104015241.GA24908@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Cheers,
David.
--
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
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
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