* Tom Lane:
Yeah. You certainly don't want to do the division sequence twice,
and a log() call wouldn't be cheap either, and there don't seem to
be many other alternatives.
What about a sequence of comparisons, and unrolling the loop? That
could avoid the final division, too. It might also
On Fri, Nov 19, 2010 at 10:18 PM, Robert Haas robertmh...@gmail.com wrote:
Sure thing. Thanks for taking time to do this - very nice speedup.
This part now committed, too.
It occurs to me belatedly that there might be a better way to do this.
Instead of flipping value from negative to
Robert Haas robertmh...@gmail.com writes:
It occurs to me belatedly that there might be a better way to do this.
Instead of flipping value from negative to positive, with a special
case for the smallest possible integer, we could do it the other
round. And actually, I think we can rid of
On Sat, Nov 20, 2010 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The trouble with that approach is that you have to depend on the
direction of rounding for negative quotients. Which was unspecified
before C99, and it's precisely pre-C99 compilers that are posing a
hazard to the current
BTW, while we're thinking about marginal improvements: instead of
constructing the string backwards and then reversing it in-place,
what about building it working backwards from the end of the buffer
and then memmove'ing it down to the start of the buffer?
I haven't tested this but it seems
On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, while we're thinking about marginal improvements: instead of
constructing the string backwards and then reversing it in-place,
what about building it working backwards from the end of the buffer
and then memmove'ing it
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
what about building it working backwards from the end of the buffer
and then memmove'ing it down to the start of the buffer?
I think that might be more clever than is really
On Saturday 20 November 2010 18:34:04 Tom Lane wrote:
BTW, while we're thinking about marginal improvements: instead of
constructing the string backwards and then reversing it in-place,
what about building it working backwards from the end of the buffer
and then memmove'ing it down to the
On Saturday 20 November 2010 18:18:32 Robert Haas wrote:
Likewise for the int64 case, which BTW is no safer for pre-C99 compilers
than it was yesterday: LL is not the portable way to write int64
constants.
Gah. I wish we had some documentation of this stuff.
Dito. I started doing Cish
Greg Stark gsst...@mit.edu writes:
On Sat, Nov 20, 2010 at 6:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I had given some thought to whether it might make sense to try to
figure out how long the string will be before we actually start
generating it, so
On Monday 15 November 2010 17:12:25 Robert Haas wrote: I notice that int8out
isn't terribly consistent with int2out and
int4out, in that it does an extra copy. Maybe that's justified given
the greater potential memory wastage, but I'm not certain. One
approach might be to pick some
On Fri, Nov 19, 2010 at 4:16 PM, Andres Freund and...@anarazel.de wrote:
On Monday 15 November 2010 17:12:25 Robert Haas wrote: I notice that int8out
isn't terribly consistent with int2out and
int4out, in that it does an extra copy. Maybe that's justified given
the greater potential memory
On Sun, Oct 31, 2010 at 5:41 PM, Andres Freund and...@anarazel.de wrote:
While at it:
These words always make me a bit frightened when reviewing a patch,
since it's generally simpler if a single patch only does one thing.
However, in this case...
* I remove the outdated
-- NOTE: int[24]
On Monday 15 November 2010 17:12:25 Robert Haas wrote:
It would speed things up for me if you or someone else could take a
quick pass over what remains here and fix the formatting and
whitespace to be consistent with our general project style, and make
the comment headers more consistent among
On sön, 2010-10-31 at 22:41 +0100, Andres Freund wrote:
* I renamed pg_[il]toa to pg_s(16|32|64)toa - I found the names
confusing. Not sure if its worth it.
Given that there are widely established functions atoi() and atol(),
naming the reverse itoa() and ltoa() makes a lot of sense. The
Peter Eisentraut pete...@gmx.net writes:
On sön, 2010-10-31 at 22:41 +0100, Andres Freund wrote:
* I renamed pg_[il]toa to pg_s(16|32|64)toa - I found the names
confusing. Not sure if its worth it.
Given that there are widely established functions atoi() and atol(),
naming the reverse
On Monday 01 November 2010 04:04:51 Itagaki Takahiro wrote:
On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund and...@anarazel.de wrote:
While looking at binary COPY performance I forgot to add BINARY and was a
bit shocked to see printf that high in the profile...
A change from 9192.476ms
Hi,
On Monday 01 November 2010 10:15:01 Andres Freund wrote:
On Monday 01 November 2010 04:04:51 Itagaki Takahiro wrote:
On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund and...@anarazel.de wrote:
While looking at binary COPY performance I forgot to add BINARY and was
a bit shocked to see
On Tuesday 02 November 2010 01:37:43 Andres Freund wrote:
Revised version attached - I will submit this to the next comittfest now.
Context diff attached this time...
diff --git a/src/backend/utils/adt/int.c b/src/backend/utils/adt/int.c
index c450333..5340052 100644
***
Hi,
While looking at binary COPY performance I forgot to add BINARY and was a bit
shocked to see printf that high in the profile...
Setup:
CREATE TABLE convtest AS SELECT a.i ai, b.i bi, a.i*b.i aibi, (a.i*b.i)::text
aibit FROM generate_series(1,1000) a(i), generate_series(1, 1) b(i);
On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund and...@anarazel.de wrote:
While looking at binary COPY performance I forgot to add BINARY and was a bit
shocked to see printf that high in the profile...
A change from 9192.476ms 5309.928ms seems to be pretty good indication that a
change in that
On Sun, Oct 31, 2010 at 11:04 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund and...@anarazel.de wrote:
While looking at binary COPY performance I forgot to add BINARY and was a bit
shocked to see printf that high in the profile...
A change
22 matches
Mail list logo
