Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YYdL0-0005mf-JJ for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Mar 2015 16:30:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YYdL0-0006Y1-0c for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Mar 2015 16:30:26 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YYdJt-0005s0-3J for pgsql-hackers@postgresql.org; Thu, 19 Mar 2015 16:29:17 +0000 Received: from mail-wg0-f52.google.com ([74.125.82.52]) by makus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YYdJk-0006MY-VD for pgsql-hackers@postgresql.org; Thu, 19 Mar 2015 16:29:15 +0000 Received: by wgbcc7 with SMTP id cc7so67094973wgb.0 for ; Thu, 19 Mar 2015 09:29:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=C2zloQJy11QnyyP32vaPWxJ8/5AIAWhh7ZOlRuWsCw4=; b=PNA8bIbp3NZqqYJXFKWcEtEaVQtJR924eyl5jBO0MhjdxDT8aUD7qCtUL79dF2DBtB kXbT6cBlD2G5iiXRkyVz4n2N99JidXd7ZZxfse5aP6BIeSgayLljyBOE79RltgfMgDe5 f2b5SLkfwMCub5bhZzPThOPa7J8KWD018Hc4ZNZL9z9jfUGAEKBKIiny+Ghfnu9P0dMx gNnAVAZFfEUT0cu0jI+orfuXgZcN5rSLRiWmsTAsQqtFFTzfgfjO6glpq1/XR/MzHfE+ xg3K6LQ6ToByKkkHqi0Qm8zDVhFMHKgHCJH1jnOmm5EqCR3PkYrD33vi9Z6uS0UsPWbN 1m/Q== X-Gm-Message-State: ALoCoQm+wAKQ9stzuhnNBO8uFjBDhGo/4zZP5ewLbm5mn1jZW04k+NQKhvuXWu5MtJBhgFOLCJ4MJrlVBfRbRw1pqL/FjSr7lvzQ4ABP2Yg5fUQjBnq5iNq6OqSahCUivLMM8/S6+iJlQt66Im/IcfqHwU3vVSft2f7jfyrTiCpaSuNT4l1MOWy5pi2KydK0/pi+6BkizysI X-Received: by 10.194.82.226 with SMTP id l2mr157013615wjy.11.1426782547009; Thu, 19 Mar 2015 09:29:07 -0700 (PDT) Received: from [192.168.1.163] (ip-78-45-139-138.net.upcbroadband.cz. [78.45.139.138]) by mx.google.com with ESMTPSA id vq9sm2614034wjc.6.2015.03.19.09.29.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 09:29:06 -0700 (PDT) Message-ID: <550AF948.3000201@2ndquadrant.com> Date: Thu, 19 Mar 2015 17:28:56 +0100 From: Tomas Vondra Organization: 2ndQuadrant User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: pgsql-hackers@postgresql.org Subject: Re: GSoC - Idea Discussion References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Hi Hitesh, On 18.3.2015 21:11, hitesh ramani wrote: > Hello devs, > > As stated earlier I was thinking to propose the integration of > Postgres and CUDA for faster execution of order by queries thru > optimizing the sorting code and sorting it with CUDA. I saw and tried > to run PG Strom and ran into issues. Moreover, PG Strom is > implemented in OpenCL, not CUDA. Could you please elaborate more why to choose CUDA, a nvidia-only technology, rather than OpenCL, supported by much wider range of companies and projects? Why do you consider OpenCL unsuitable? Not that CUDA is bad - it certainly works better in some scenarios, but this is a cost/benefits question, and it only works with devices manufactured by a single company. That significantly limits the usefulness of the work, IMHO. You mention that you ran into issues with PG Strom. What issues? > > I have hardware to run CUDA and currently I'm at a point where I > have almost integrated Postgres and CUDA. This opens up gates for a > lot of features which can be optimized thru CUDA and parallel > processing, though here I only want to focus on sorting, hence kind > of feasible for the time period. Can we see some examples, what this actually means? What you can and can't do at this point, etc.? Can you share some numbers how this improves the performance? > > As I did some research, I found CUDA is more efficient in not just > the parallel performance but data transfer latency too. My idea is to > create a branch of Postgres with the CUDA integrated code. > More efficient than what? > > For the feasibility, I guess it's very much feasible because I've > almost integrated CUDA execution and the code needs to be optimized > as per CUDA. That's really difficult to judge, because you have not provided any source code, examples or anything else to support this. > > Please give in your valuable suggestions and views on this. From where I sit, this looks interesting, but rather as a research project rather than something than can be integrated into PostgreSQL in a foreseeable future. Not sure that's what GSoC is intended for. Also, we badly need more details on this - current status, examples, and especially project plan explaining the scope. It's impossible to say whether the sort can be implemented within the GSoC time frame. -- Tomas Vondra http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers