Subject: Re: asynchronous and vectorized execution
To: Kouhei Kaigai <kaigai@ak.jp.nec.com>, David Rowley
	<david.rowley@2ndquadrant.com>
References: 
 <CA+Tgmobx8su_bYtAa3DgrqB+R7xZG6kHRj0ccMUUshKAQVftww@mail.gmail.com>
 <9A28C8860F777E439AA12E8AEA7694F8011EE07C@BPXM15GP.gisp.nec.co.jp>
 <CAKJS1f-TnaeDbC_K8FJTbV=ArRYb+V3sEr-ayvqqYVSNXCXQLQ@mail.gmail.com>
 <9A28C8860F777E439AA12E8AEA7694F8011F0224@BPXM15GP.gisp.nec.co.jp>
CC: Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org"
	<pgsql-hackers@postgresql.org>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
Message-ID: <e09abfe6-fddf-64de-bfac-1aab7f5fff14@BlueTreble.com>
Date: Tue, 10 May 2016 15:57:32 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: 
 <9A28C8860F777E439AA12E8AEA7694F8011F0224@BPXM15GP.gisp.nec.co.jp>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2016 20:57:38.1393 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR11MB0686
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 5/10/16 12:47 AM, Kouhei Kaigai wrote:
>> > On 10 May 2016 at 13:38, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote:
>>> > > My concern about ExecProcNode is, it is constructed with a large switch
>>> > > ... case statement. It involves tons of comparison operation at run-time.
>>> > > If we replace this switch ... case by function pointer, probably, it make
>>> > > performance improvement. Especially, OLAP workloads that process large
>>> > > amount of rows.
>> >
>> > I imagined that any decent compiler would have built the code to use
>> > jump tables for this. I have to say that I've never checked to make
>> > sure though.
>> >
> Ah, indeed, you are right. Please forget above part.

Even so, I would think that the simplification in the executor would be 
worth it. If you need to add a new node there's dozens of places where 
you might have to mess with these giant case statements.

In python (for example), types (equivalent to nodes in this case) have 
data structures that define function pointers for a core set of 
operations (such as doing garbage collection, or generating a string 
representation). That means that to add a new type at the C level you 
only need to define a C structure that has the expected members, and an 
initializer function that will properly set everything up when you 
create a new instance. There's no messing around with the rest of the 
guts of python.

*Even more important, everything you need to know about the type is 
contained in one place, not spread throughout the code.*
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers