Hi Mark,
Vitesse DB won't be open-sourced, or it would have been a contrib
module to postgres. We should take further discussions off this list.
People should contact me directly if there is any questions.
Thanks,
ck...@vitessedata.com
On Fri, Oct 17, 2014 at 10:55 PM, Mark Kirkwood
wrote:
>
On 18/10/14 07:13, Josh Berkus wrote:
CK,
Before we go any further on this, how is Vitesse currently licensed?
last time we talked it was still proprietary. If it's not being
open-sourced, we likely need to take discussion off this list.
+1
Guys, you need to 'fess up on the licensing!
Rega
Indeed! A big part of our implementation is based on the Neumann
paper. There are also a few other papers that impacted our
implemented:
A. Ailamaki, D. DeWitt, M. Hill, D. Wood. DBMSs On A Modern Processor:
Where Does Time Go?
Peter Boncz, Marcin Zukowski, Niels Nes. MonetDB/X100:
Hyper-Pipelini
On Fri, 17 Oct 2014 13:12:27 -0400
Tom Lane wrote:
> CK Tan 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
Happy to contribute to that decision :-)
On Fri, Oct 17, 2014 at 11:35 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2014-10-17 13:12:27 -0400, Tom Lane wrote:
>>> Well, that's pretty much cheating: it's too hard to disentangle what's
>>> coming from JIT vs what's coming from using a differ
Andres Freund writes:
> On 2014-10-17 13:12:27 -0400, Tom Lane wrote:
>> 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 tha
On Fri, Oct 17, 2014 at 1:21 PM, Peter Geoghegan wrote:
> On Fri, Oct 17, 2014 at 11:08 AM, Feng Tian 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 in
On 2014-10-17 13:12:27 -0400, Tom Lane wrote:
> 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
On Fri, Oct 17, 2014 at 11:08 AM, Feng Tian 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 faste
CK,
Before we go any further on this, how is Vitesse currently licensed?
last time we talked it was still proprietary. If it's not being
open-sourced, we likely need to take discussion off this list.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailin
Hi, Tom,
Sorry for double post to you.
Feng
-- Forwarded message --
From: Feng Tian
Date: Fri, Oct 17, 2014 at 10:29 AM
Subject: Re: [HACKERS] Vitesse DB call for testing
To: Tom Lane
Hi, Tom,
I agree using that using int128 in stock postgres will speed up things
too. On
CK Tan 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 executio
On Fri, Oct 17, 2014 at 10:47 AM, CK Tan wrote:
> Merlin, glad you tried it.
>
> We take the query plan exactly as given by the planner, decide whether to JIT
> or to punt depending on the cost. If we punt, it goes back to pg executor. If
> we JIT, and if we could not proceed (usually of some op
Merlin, glad you tried it.
We take the query plan exactly as given by the planner, decide whether to JIT
or to punt depending on the cost. If we punt, it goes back to pg executor. If
we JIT, and if we could not proceed (usually of some operators we haven't
implemented yet), we again punt. Once
On Fri, Oct 17, 2014 at 8:14 AM, Merlin Moncure wrote:
> On Fri, Oct 17, 2014 at 7:32 AM, CK Tan wrote:
>> Hi everyone,
>>
>> Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
>> designed for compute intensive OLAP workload. We have gotten it to a
>> reasonable state and would l
On Fri, Oct 17, 2014 at 7:32 AM, CK Tan wrote:
> Hi everyone,
>
> Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
> designed for compute intensive OLAP workload. We have gotten it to a
> reasonable state and would like to open it up to the pg hackers
> community for testing and
Hi,
On 2014-10-17 05:32:13 -0700, CK Tan wrote:
> Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
> designed for compute intensive OLAP workload. We have gotten it to a
> reasonable state and would like to open it up to the pg hackers
> community for testing and suggestions.
>
Hi everyone,
Vitesse DB 9.3.5.S is Postgres 9.3.5 with a LLVM-JIT query executor
designed for compute intensive OLAP workload. We have gotten it to a
reasonable state and would like to open it up to the pg hackers
community for testing and suggestions.
Vitesse DB offers
-- JIT Compilation for com
18 matches
Mail list logo
