Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 7/02/2016 4:14 am, "Tom Lane" wrote: > > David Rowley writes: > [ timestamp_out_speedup_2015-11-05.patch ] > > Pushed with a bunch of cosmetic tweaks. Great. Thanks for pushing this. David

Re: [HACKERS] WIP: Make timestamptz_out less slow.

David Rowley writes: [ timestamp_out_speedup_2015-11-05.patch ] Pushed with a bunch of cosmetic tweaks. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 29 November 2015 at 14:00, Peter Geoghegan wrote: > On Sun, Nov 22, 2015 at 2:20 AM, David Rowley > wrote: > > Just to confirm, you mean this comment? > > > > int tm_year; /* relative to 1900 */ > > > > Please let me know if you disagree, but

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On Sun, Nov 22, 2015 at 2:20 AM, David Rowley wrote: > Just to confirm, you mean this comment? > > int tm_year; /* relative to 1900 */ > > Please let me know if you disagree, but I'm not sure it's the business of > this patch to fix that. If it's wrong now, then it

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 12 November 2015 at 13:44, Peter Geoghegan wrote: > On Wed, Nov 4, 2015 at 6:30 PM, David Rowley > wrote: > >> Have you thought about *just* having an int64 pg_ltostr()? Are you > >> aware of an appreciable overhead from having int32 callers

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On Wed, Nov 4, 2015 at 6:30 PM, David Rowley wrote: >> Have you thought about *just* having an int64 pg_ltostr()? Are you >> aware of an appreciable overhead from having int32 callers just rely >> on a promotion to int64? > > I'd not thought of that. It would

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On Fri, Sep 11, 2015 at 9:00 AM, David Rowley wrote: > Attached is also timestamp_delta.patch which changes pg_ltostr() to use the > INT_MIN special case that pg_ltoa also uses. I didn't make a similar change > to pg_ltostr_zeropad() as I'd need to add even more

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 5 November 2015 at 13:20, Peter Geoghegan wrote: > On Fri, Sep 11, 2015 at 9:00 AM, David Rowley > wrote: > > Attached is also timestamp_delta.patch which changes pg_ltostr() to use > the > > INT_MIN special case that pg_ltoa also uses. I didn't

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-09-14 12:03:31 -0500, Jim Nasby wrote: > On 9/13/15 2:43 AM, David Rowley wrote: > >Are you worried about this because I've not focused on optimising float > >timestamps as much as int64 timestamps? Are there many people compiling > >with float timestamps in the real world? > > My $0.02:

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 9/13/15 2:43 AM, David Rowley wrote: Are you worried about this because I've not focused on optimising float timestamps as much as int64 timestamps? Are there many people compiling with float timestamps in the real world? My $0.02: the default was changed some 5 years ago so FP time is

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 15 September 2015 at 05:52, Alvaro Herrera wrote: > Jim Nasby wrote: > > On 9/13/15 2:43 AM, David Rowley wrote: > > >Are you worried about this because I've not focused on optimising float > > >timestamps as much as int64 timestamps? Are there many people compiling

Re: [HACKERS] WIP: Make timestamptz_out less slow.

David Rowley wrote: > It's not like nothing is improved in float timestamps with this patch, it's > only appending the non-zero fractional seconds that I've left alone. Every > other portion of the timestamp has been improved. OK, sounds good enough to me. > I did, however spend some time a few

Re: [HACKERS] WIP: Make timestamptz_out less slow.

Jim Nasby wrote: > On 9/13/15 2:43 AM, David Rowley wrote: > >Are you worried about this because I've not focused on optimising float > >timestamps as much as int64 timestamps? Are there many people compiling > >with float timestamps in the real world? > > My $0.02: the default was changed some

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 12 September 2015 at 04:24, Andres Freund wrote: > On 2015-09-12 04:00:26 +1200, David Rowley wrote: > > I've not done anything yet to remove the #ifdef HAVE_INT64_TIMESTAMP from > > AppendSeconds(). The only way I can think to handle this is to just > > make fsec_t

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 3 September 2015 at 05:10, Andres Freund wrote: > > +/* > > + * pg_int2str > > + * Converts 'value' into a decimal string representation of > the number. > > + * > > + * Caller must ensure that 'str' points to enough memory to hold the > result > > + * (at least

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-09-12 04:00:26 +1200, David Rowley wrote: > I've not done anything yet to remove the #ifdef HAVE_INT64_TIMESTAMP from > AppendSeconds(). The only way I can think to handle this is to just > make fsec_t unconditionally an int64 (since with float datetimes the > precision is 10 decimal

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 3 September 2015 at 22:17, Andres Freund wrote: > On 2015-09-03 16:28:40 +1200, David Rowley wrote: > > > Wouldn't it be better to just normalize fsec to an integer in that > case? > > > Afaics that's the only remaining reason for the alternative path? > > > > > > A

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-09-03 16:28:40 +1200, David Rowley wrote: > > Wouldn't it be better to just normalize fsec to an integer in that case? > > Afaics that's the only remaining reason for the alternative path? > > > > A special case would need to exist somewhere, unless we just modified > timestamp2tm() to

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 3 September 2015 at 22:17, Andres Freund wrote: > On 2015-09-03 16:28:40 +1200, David Rowley wrote: > > I experimented with finding the fastest way to convert an int to a string > > at the weekend, I did happen to be testing with int64's but likely int32 > > will be the

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-08-09 12:47:53 +1200, David Rowley wrote: > I took a bit of weekend time to finish this one off. Patch attached. > > A quick test shows a pretty good performance increase: > > create table ts (ts timestamp not null); > insert into ts select generate_series('2010-01-01 00:00:00',

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 3 September 2015 at 05:10, Andres Freund wrote: > On 2015-08-09 12:47:53 +1200, David Rowley wrote: > > I took a bit of weekend time to finish this one off. Patch attached. > > > > A quick test shows a pretty good performance increase: > > > > create table ts (ts timestamp

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 29 July 2015 at 03:25, Andres Freund and...@anarazel.de wrote: On 2015-07-29 03:10:41 +1200, David Rowley wrote: timestamp_out() = 2015-07-29 02:24:33.34 in 3.506000 timestamp_out_old() = 2015-07-29 02:24:33.034 in 64.518000 timestamp_out_af() = 2015-07-29 02:24:33.034 in 2.981000

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 5 August 2015 at 12:51, David Rowley david.row...@2ndquadrant.com wrote: On 29 July 2015 at 03:25, Andres Freund and...@anarazel.de wrote: On 2015-07-29 03:10:41 +1200, David Rowley wrote: timestamp_out() = 2015-07-29 02:24:33.34 in 3.506000 timestamp_out_old() = 2015-07-29 02:24:33.034

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 29 July 2015 at 03:25, Andres Freund and...@anarazel.de wrote: On 2015-07-29 03:10:41 +1200, David Rowley wrote: timestamp_out() = 2015-07-29 02:24:33.34 in 3.506000 timestamp_out_old() = 2015-07-29 02:24:33.034 in 64.518000 timestamp_out_af() = 2015-07-29 02:24:33.034 in 2.981000

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-07-29 09:37:26 +1200, David Rowley wrote: On 29 July 2015 at 03:25, Andres Freund and...@anarazel.de wrote: On 2015-07-29 03:10:41 +1200, David Rowley wrote: Have you thought about what to do when HAVE_INT64_TIMESTAMP is not defined? I don't think it's actually important. The

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-07-28 10:59:15 +1200, David Rowley wrote: It won't be quite as fast as what you've written, but I think it will be much neater and more likely to be used in other places if we invent a function like pg_ltoa() which returns a pointer to the new end of string. Also if we're specifying

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 28 July 2015 at 19:10, Andres Freund and...@anarazel.de wrote: On 2015-07-28 10:59:15 +1200, David Rowley wrote: It won't be quite as fast as what you've written, but I think it will be much neater and more likely to be used in other places if we invent a function like pg_ltoa() which

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-07-29 03:10:41 +1200, David Rowley wrote: timestamp_out() = 2015-07-29 02:24:33.34 in 3.506000 timestamp_out_old() = 2015-07-29 02:24:33.034 in 64.518000 timestamp_out_af() = 2015-07-29 02:24:33.034 in 2.981000 timestamp_out_old is master's version, the timestamp_out_af() is yours,

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 29 July 2015 at 03:25, Andres Freund and...@anarazel.de wrote: On 2015-07-29 03:10:41 +1200, David Rowley wrote: Have you thought about what to do when HAVE_INT64_TIMESTAMP is not defined? I don't think it's actually important. The only difference vs float timestamps is that in the

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 2015-07-27 17:31:41 -0400, Tom Lane wrote: Andres Freund and...@anarazel.de writes: So nearly all the time is spent somewhere inside the sprintf calls. Not nice. What happens if you force use of port/snprintf.c instead of glibc's version? Good question. Even worse. 15900.014 ms.

Re: [HACKERS] WIP: Make timestamptz_out less slow.

Andres Freund and...@anarazel.de writes: So nearly all the time is spent somewhere inside the sprintf calls. Not nice. What happens if you force use of port/snprintf.c instead of glibc's version? regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] WIP: Make timestamptz_out less slow.

Andres Freund and...@anarazel.de writes: On 2015-07-27 17:31:41 -0400, Tom Lane wrote: What happens if you force use of port/snprintf.c instead of glibc's version? Even worse. 15900.014 ms. Interesting. So as a separate optimization problem, we might consider try to put snprintf.c at least

Re: [HACKERS] WIP: Make timestamptz_out less slow.

On 28 July 2015 at 09:17, Andres Freund and...@anarazel.de wrote: Hi, I recently once more noticed that timestamptz_out is really, really slow. To quantify that, I created a bunch of similar sized tables: CREATE TABLE tbl_timestamp AS SELECT NOW() FROM generate_series(1, 10) a,