On 20 June 2013 06:45, Craig Ringer cr...@2ndquadrant.com wrote:
I think a good starting point would be to use the Intel and IBM
libraries to implement basic DECIMAL32/64/128 to see if they perform
better than the gcc builtins tested by Pavel by adapting his extension.
If the performance
On 20 June 2013 06:45, Craig Ringer cr...@2ndquadrant.com wrote:
I think a good starting point would be to use the Intel and IBM
libraries to implement basic DECIMAL32/64/128 to see if they perform
better than the gcc builtins tested by Pavel by adapting his extension.
Just a few notes:
Not
On 20 June 2013 08:05, Thomas Munro mu...@ip9.org wrote:
On 20 June 2013 06:45, Craig Ringer cr...@2ndquadrant.com wrote:
If the performance isn't interesting it may still be worth adding for
compliance reasons, but if we can only add IEEE-compliant decimal FP by
using non-SQL-standard type
On 2013-06-20 13:45:24 +0800, Craig Ringer wrote:
On 06/12/2013 07:51 PM, Andres Freund wrote:
On 2013-06-12 19:47:46 +0800, Craig Ringer wrote:
On 06/12/2013 05:55 PM, Greg Stark wrote:
On Wed, Jun 12, 2013 at 12:56 AM, Craig Ringer cr...@2ndquadrant.com
wrote:
The main thing I'm
On 06/12/2013 07:51 PM, Andres Freund wrote:
On 2013-06-12 19:47:46 +0800, Craig Ringer wrote:
On 06/12/2013 05:55 PM, Greg Stark wrote:
On Wed, Jun 12, 2013 at 12:56 AM, Craig Ringer cr...@2ndquadrant.com
wrote:
The main thing I'm wondering is how/if to handle backward compatibility
with
On 2013-06-12 19:47:46 +0800, Craig Ringer wrote:
On 06/12/2013 05:55 PM, Greg Stark wrote:
On Wed, Jun 12, 2013 at 12:56 AM, Craig Ringer cr...@2ndquadrant.com
wrote:
The main thing I'm wondering is how/if to handle backward compatibility
with
the existing NUMERIC and its DECIMAL
