Date: Sun, 15 Sep 2019 18:12:03 +0200
From: David Fetter <david@fetter.org>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: Efficient output for integer types
Message-ID: <20190915161203.GL31596@fetter.org>
References: <20190915071848.GK31596@fetter.org>
 <E024B828-A33F-451A-AFE0-F1C98A4F8F7C@yandex-team.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E024B828-A33F-451A-AFE0-F1C98A4F8F7C@yandex-team.ru>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Sun, Sep 15, 2019 at 02:06:29PM +0500, Andrey Borodin wrote:
> > 15 сент. 2019 г., в 12:18, David Fetter <david@fetter.org> написал(а):
> > 
> > Please find attached a couple of patches intended to $subject.
> > 
> > This patch set cut the time to copy ten million rows of randomly sized
> > int8s (10 of them) by about a third, so at least for that case, it's
> > pretty decent.
> 
> Hi! Looks cool.
> 
> Just curious if for any fixed base and square here
> 
> +		while(uvalue >= base)
>  		{
> +			const int i = (uvalue % square) * 2;
> +			uvalue /= square;
> +			vallen += 2;
> +			memcpy(convert + sizeof(convert) - vallen, digits + i, 2);
> +		}
> 
> compiler will have a chance to avoid idiv instruction?

That could very well be.  I took the idea (and most of the code) from
the Ryū implementation Andrew Gierth committed for 12.

> Maybe few specialized functions could work better than generic
> algorithm?

Could be.  What do you have in mind?  I'm guessing that the ones for
decimals, that being both the most common case and the least obvious
as to how to optimize, would give the most benefit.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate