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
>> documentation changes in commit
>> 8472bf7a734
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 enough.
I ask because at
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
>> from any computational optimizations,
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 pass-by-value rather tha
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
> project, but I could be w
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 untrained eye it looks rather BSD-ish -- and
>> 20kloc isn't v
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 isn't viewed as excessive), and furt
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 would be the point of that?
>
>>> We'd accept and display the new SQL:2016 standard type name with
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 standard type name with
>> length, but by mapping it onto different internal type
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 Haas wrote:
I feel like these would logically just be different types, like int
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 different types, like int4
>>> and int8 are. We don't have integer(9) and integer(18)
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 DECFLOAT(9) [= 32 bit] and DECFLOAT(17)
>>> [= 64 bit] could in theory be passed by value. Of c
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 we don't
>> have a way to make those pass-by-value and
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) [=
> 128 bit] by reference! That is
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
>> just saw this on Markus Winand's Modern SQL blog:
>>
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 worry about the implicit casts you've added. They might cause
problems.
>>>
>
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.
>>
>>
>> Given the cycle created between numeric->decimal and d
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 guarantee they will. In any c
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
> pretty much guarantee they w
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 ju
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 numeric->de
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 wrote:
>>> > Please include the actual patch as an attachment. We do n
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
> workload, decimal may tak
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 consider
>> mere
>> > URLs to be acceptable patch submission fo
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 provides no
> > permanent record in our arch
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 impression that this wa
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 submitted.
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 the decimal types
would
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
>
>
> http://www.postgre
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
http://www.postgresql.org/message-id/CAFj8pRApakE6s-H2yJcXD=ubpukwa6i7rx4vuvtb4puhga5.
30 matches
Mail list logo
