Re: asynchronous and vectorized execution - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: asynchronous and vectorized execution
Date
Msg-id e09abfe6-fddf-64de-bfac-1aab7f5fff14@BlueTreble.com
Whole thread Raw
In response to Re: asynchronous and vectorized execution  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Responses Re: asynchronous and vectorized execution  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pg_dump dump catalog ACLs
Next
From: Andres Freund
Date:
Subject: Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)