Re: Vitesse DB call for testing

On Fri, Oct 17, 2014 at 1:21 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Fri, Oct 17, 2014 at 11:08 AM, Feng Tian <ftian(at)vitessedata(dot)com> wrote:
>> I agree using that using int128 in stock postgres will speed up things too.
>> On the other hand, that is only one part of the equation. For example, if
>> you look at TPCH Q1, the int128 "cheating" does not kick in at all, but we
>> are 8x faster.
>
> I'm curious about how the numbers look when stock Postgres is built
> with the same page size as your fork. You didn't mention whether or
> not your Postgres numbers came from a standard build.

I downloaded the 8kb varant.

vitesse (median of 3):
postgres=# select count(*), sum(i*i), avg(i) from t;
count │ sum │ avg
─────────┼────────────────────┼─────────────────────
1000000 │ 333333833333500000 │ 500000.500000000000
(1 row)

Time: 39.197 ms

stock (median of 3):
postgres=# select count(*), sum(i*i), avg(i) from t;
count │ sum │ avg
─────────┼────────────────────┼─────────────────────
1000000 │ 333333833333500000 │ 500000.500000000000
(1 row)

Time: 667.362 ms

(stock int4 ops)
postgres=# select sum(1::int4) from t;
sum
─────────
1000000
(1 row)

Time: 75.265 ms

What I'm wondering is how complex the hooks are that tie the
technology in. Unless a bsd licensed patch materializes, the
conversation (beyond the intitial wow! factor) should probably focus
on a possible integration points and/or implementation of technology
into core in a general way.

merlin