PG-Strom - A GPU optimized asynchronous executor module - Mailing list pgsql-hackers

From Kohei KaiGai
Subject PG-Strom - A GPU optimized asynchronous executor module
Date
Msg-id CADyhKSXF7ysbM-NUf571+XAi2ykm=b-RP2vfHdwANp7D0PXKTA@mail.gmail.com
Whole thread Raw
Responses Re: PG-Strom - A GPU optimized asynchronous executor module
Re: PG-Strom - A GPU optimized asynchronous executor module
List pgsql-hackers
Hi,

I tried to implement a fdw module that is designed to utilize GPU
devices to execute
qualifiers of sequential-scan on foreign tables managed by this module.

It was named PG-Strom, and the following wikipage gives a brief
overview of this module.   http://wiki.postgresql.org/wiki/PGStrom

In our measurement, it achieves about x10 times faster on
sequential-scan with complex-
qualifiers, of course, it quite depends on type of workloads.

Example)
A query counts number of records with (x,y) located within a particular range.
A regular table 'rtbl' and foreign table 'ftbl' contains same
contents; with 10 million of records.

postgres=# SELECT count(*) FROM rtbl WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 51.2;count
-------43134
(1 row)

Time: 10537.069 ms

postgres=# SELECT count(*) FROM ftbl WHERE sqrt((x-25.6)^2 + (y-12.8)^2) < 51.2;count
-------43134
(1 row)

Time: 744.252 ms

(*) Let's see the "How to use" section of the wikipage to reproduce my testcase.

It seems to me quite good result. However, I doubt myself whether the case of
sequential-scan on regular table was not tuned appropriately.
Could you tell me some hint to tune up sequential scan on large tables?
All I did on the test case is expansion of shared_buffers to 1024MB that is
enough to load whole of the example tables on memory.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: [v9.2] sepgsql's DROP Permission checks
Next
From: Julien Tachoires
Date:
Subject: Re: patch : Allow toast tables to be moved to a different tablespace