Re: Vitesse DB call for testing

From: David Gould <daveg(at)sonic(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: CK Tan <cktan(at)vitessedata(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vitesse DB call for testing
Date: 2014-10-18 03:40:14
Message-ID: 20141017204014.07f3755c@jekyl.lan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 17 Oct 2014 13:12:27 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> CK Tan <cktan(at)vitessedata(dot)com> writes:
> > The bigint sum,avg,count case in the example you tried has some optimization. We use int128 to accumulate the bigint instead of numeric in pg. Hence the big speed up. Try the same query on int4 for the improvement where both pg and vitessedb are using int4 in the execution.
>
> Well, that's pretty much cheating: it's too hard to disentangle what's
> coming from JIT vs what's coming from using a different accumulator
> datatype. If we wanted to depend on having int128 available we could
> get that speedup with a couple hours' work.
>
> But what exactly are you "compiling" here? I trust not the actual data
> accesses; that seems far too complicated to try to inline.
>
> regards, tom lane
>
>

I don't have any inside knowledge, but from the presentation given at the
recent SFPUG followed by a bit of google-fu I think these papers are
relevant:

http://www.vldb.org/pvldb/vol4/p539-neumann.pdf
http://sites.computer.org/debull/A14mar/p3.pdf

-dg

--
David Gould 510 282 0869 daveg(at)sonic(dot)net
If simplicity worked, the world would be overrun with insects.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message MauMau 2014-10-18 04:13:03 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Tom Lane 2014-10-18 03:16:08 Re: get_actual_variable_range vs idx_scan/idx_tup_fetch