On Fri, Oct 17, 2014 at 1:21 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Fri, Oct 17, 2014 at 11:08 AM, Feng Tian <ft...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
