Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 3:47 PM, Peter Geoghegan wrote: > On Mon, Jun 19, 2017 at 12:19 PM, Robert Haas wrote: >> I don't have a specific use case in mind. However, datumCopy() is >> sure to be a lot faster when typByVal is true, and see also the >>

Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 12:19 PM, Robert Haas wrote: > I don't have a specific use case in mind. However, datumCopy() is > sure to be a lot faster when typByVal is true, and see also the > documentation changes in commit > 8472bf7a73487b0535c95e299773b882f7523463. Fair

Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 1:10 PM, Peter Geoghegan wrote: > On Mon, Jun 19, 2017 at 10:00 AM, Robert Haas wrote: >> I've never been very happy with the performance of numeric, so I guess >> I'm a bit more optimistic about the chances of doing better. Aside >>

Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 10:00 AM, Robert Haas wrote: > I've never been very happy with the performance of numeric, so I guess > I'm a bit more optimistic about the chances of doing better. Aside > from any computational optimizations, the fact that the datatype could > be

Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 12:18 PM, Tom Lane wrote: > It would be interesting to get some handle on the performance differences > between decNumber and our existing NUMERIC implementation. I'm a little > skeptical that they'd be so enormous as to make this an interesting >

Re: [HACKERS] Decimal64 and Decimal128

Robert Haas writes: > On Sun, Jun 18, 2017 at 6:28 PM, Thomas Munro > wrote: >> I speculate that decNumber in-tree would be the path of least >> resistance (assuming the "ICU 1.8.1 and later" license[4] would be >> acceptable -- to my

Re: [HACKERS] Decimal64 and Decimal128

On Sun, Jun 18, 2017 at 6:28 PM, Thomas Munro wrote: > I speculate that decNumber in-tree would be the path of least > resistance (assuming the "ICU 1.8.1 and later" license[4] would be > acceptable -- to my untrained eye it looks rather BSD-ish -- and > 20kloc

Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 2:24 AM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Jun 17, 2017 at 11:58 PM, Thomas Munro >> wrote: >>> On Sun, Jun 18, 2017 at 2:31 PM, Robert Haas wrote: What

Re: [HACKERS] Decimal64 and Decimal128

Robert Haas writes: > On Sat, Jun 17, 2017 at 11:58 PM, Thomas Munro > wrote: >> On Sun, Jun 18, 2017 at 2:31 PM, Robert Haas wrote: >>> What would be the point of that? >> We'd accept and display the new SQL:2016

Re: [HACKERS] Decimal64 and Decimal128

On Sat, Jun 17, 2017 at 11:58 PM, Thomas Munro wrote: > On Sun, Jun 18, 2017 at 2:31 PM, Robert Haas wrote: >> On Sat, Jun 17, 2017 at 3:50 PM, Thomas Munro >> wrote: >>> On Sun, Jun 18, 2017 at 5:38 AM, Robert

Re: [HACKERS] Decimal64 and Decimal128

On Sun, Jun 18, 2017 at 2:31 PM, Robert Haas wrote: > On Sat, Jun 17, 2017 at 3:50 PM, Thomas Munro > wrote: >> On Sun, Jun 18, 2017 at 5:38 AM, Robert Haas wrote: >>> I feel like these would logically just be

Re: [HACKERS] Decimal64 and Decimal128

On Sat, Jun 17, 2017 at 3:50 PM, Thomas Munro wrote: > On Sun, Jun 18, 2017 at 5:38 AM, Robert Haas wrote: >> On Thu, Jun 15, 2017 at 10:27 PM, Thomas Munro >> wrote: >>> 1. They are fixed size, and

Re: [HACKERS] Decimal64 and Decimal128

On Sun, Jun 18, 2017 at 5:38 AM, Robert Haas wrote: > On Thu, Jun 15, 2017 at 10:27 PM, Thomas Munro > wrote: >> 1. They are fixed size, and DECFLOAT(9) [= 32 bit] and DECFLOAT(17) >> [= 64 bit] could in theory be passed by value. Of course

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Jun 15, 2017 at 10:27 PM, Thomas Munro wrote: > 1. They are fixed size, and DECFLOAT(9) [= 32 bit] and DECFLOAT(17) > [= 64 bit] could in theory be passed by value. Of course we don't > have a way to make those pass-by-value and yet pass DECFLOAT(34) [= >

Re: [HACKERS] Decimal64 and Decimal128

On Fri, Jun 16, 2017 at 1:24 PM, Craig Ringer wrote: > On 16 June 2017 at 05:42, Thomas Munro wrote: >> Bumping this ancient thread to say that DECFLOAT appears to have >> landed in the SQL standard. I haven't looked at SQL:2016 myself by I

Re: [HACKERS] Decimal64 and Decimal128

On 16 June 2017 at 05:42, Thomas Munro wrote: > On Fri, Sep 25, 2015 at 5:06 PM, Pavel Stehule > wrote: >> 2015-09-25 0:25 GMT+02:00 Jim Nasby : >>> >>> On 9/24/15 3:35 PM, Peter Geoghegan wrote: I would

Re: [HACKERS] Decimal64 and Decimal128

On Fri, Sep 25, 2015 at 5:06 PM, Pavel Stehule wrote: > 2015-09-25 0:25 GMT+02:00 Jim Nasby : >> >> On 9/24/15 3:35 PM, Peter Geoghegan wrote: >>> >>> I would worry about the implicit casts you've added. They might cause >>> problems. >> >> >>

[HACKERS] Decimal64 and Decimal128

Hi, Here is an extension for 64 and 128 bit decimal types using IEEE decimal floating point. The original idea/implementation is from http://pgxn.org/dist/pgdecimal/1.0.0/ Original thread for dicussion is at

Re: [HACKERS] Decimal64 and Decimal128

On Fri, Sep 25, 2015 at 9:23 AM, Feng Tian wrote: > > > On Thu, Sep 24, 2015 at 2:17 PM, Feng Tian wrote: >> >> >> >> On Thu, Sep 24, 2015 at 1:55 PM, Peter Geoghegan wrote: >>> >>> On Thu, Sep 24, 2015 at 1:53 PM, Tom Lane

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 1:29 PM, Feng Tian wrote: > Here is an extension for 64 and 128 bit decimal types using IEEE decimal > floating point. The original idea/implementation is from > http://pgxn.org/dist/pgdecimal/1.0.0/ Interesting. A default B-Tree operator class for

Re: [HACKERS] Decimal64 and Decimal128

On 9/24/15 3:35 PM, Peter Geoghegan wrote: I would worry about the implicit casts you've added. They might cause problems. Given the cycle created between numeric->decimal and decimal->numeric, I can pretty much guarantee they will. In any case, I don't think implicit casting from

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 1:53 PM, Tom Lane wrote: > Please include the actual patch as an attachment. We do not consider mere > URLs to be acceptable patch submission format, because that provides no > permanent record in our archives of what was submitted. I was under the

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 1:55 PM, Peter Geoghegan wrote: > On Thu, Sep 24, 2015 at 1:53 PM, Tom Lane wrote: > > Please include the actual patch as an attachment. We do not consider > mere > > URLs to be acceptable patch submission format, because that

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 2:17 PM, Feng Tian wrote: > > > On Thu, Sep 24, 2015 at 1:55 PM, Peter Geoghegan wrote: > >> On Thu, Sep 24, 2015 at 1:53 PM, Tom Lane wrote: >> > Please include the actual patch as an attachment. We do not

Re: [HACKERS] Decimal64 and Decimal128

On Thu, Sep 24, 2015 at 1:29 PM, Feng Tian wrote: > Hi, > > Here is an extension for 64 and 128 bit decimal types using IEEE decimal > floating point. The original idea/implementation is from > http://pgxn.org/dist/pgdecimal/1.0.0/ Original thread for dicussion is > at

Re: [HACKERS] Decimal64 and Decimal128

On Fri, Sep 25, 2015 at 10:25 AM, Jim Nasby wrote: > On 9/24/15 3:35 PM, Peter Geoghegan wrote: >> >> I would worry about the implicit casts you've added. They might cause >> problems. > > > Given the cycle created between numeric->decimal and decimal->numeric, I can >

Re: [HACKERS] Decimal64 and Decimal128

2015-09-25 0:25 GMT+02:00 Jim Nasby : > On 9/24/15 3:35 PM, Peter Geoghegan wrote: > >> I would worry about the implicit casts you've added. They might cause >> problems. >> > > Given the cycle created between numeric->decimal and decimal->numeric, I > can pretty much

Re: [HACKERS] Decimal64 and Decimal128

Feng Tian writes: > Ah, link. > https://github.com/vitesse-ftian/pgdecimal Please include the actual patch as an attachment. We do not consider mere URLs to be acceptable patch submission format, because that provides no permanent record in our archives of what was

Re: [HACKERS] Decimal64 and Decimal128

On 25 September 2015 at 08:29, Feng Tian wrote: > Compared to numeric type, decimal64 arithmetics is about 2x faster, > decimal128 is about 1.5x faster. However, the cast between decimal and > float4/8 is implemented rather naively and slow. As always, it depends on >

Re: [HACKERS] Decimal64 and Decimal128

On 09/24/2015 02:23 PM, Feng Tian wrote: > If there is enough interest, would be great for it to go into the > official contrib dir. > Thanks, > > > Second thought, the extension depends on decNumber, which is either GPL, > or ICU license. Maybe this is trouble. > Yes. Please