Re: NUMERIC private methods?

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: NUMERIC private methods?
Date: 2014-12-18 05:11:51
Message-ID: 87fvcdljq2.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

>> Hmm. You'd want to make add_var, mul_var etc. non-static?

Tom> -1 for that.

possibly with more meaningful names.

Tom> If you're concerned about arithmetic performance, there is a
Tom> very obvious fix here: use double.

Independently of this specific example, the obvious issue there is that
there are applications for which double is simply not acceptable.

As it stands, no extension can use the numeric type in any non-trivial
way without paying a large penalty for repeated pallocs and data copies.
Given that the ability to write C extensions easily is one of pg's great
strengths, this is a defect that should be corrected.

Tom> (It would still be orders of magnitude slower, no matter how
Tom> much we were willing to destroy numeric.c's modularity
Tom> boundary.)

There is no need to expose any details of NumericVar's implementation;
it would suffice to provide an interface to allocate NumericVars, and
access to the functions.

--
Andrew (irc:RhodiumToad)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2014-12-18 05:16:12 Re: TABLESAMPLE patch
Previous Message Michael Paquier 2014-12-18 04:12:06 Re: [REVIEW] Re: Compression of full-page-writes