On Fri, Oct 17, 2014 at 1:21 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Fri, Oct 17, 2014 at 11:08 AM, Feng Tian <ftian@vitessedata.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