Re: asynchronous and vectorized execution
От | Kouhei Kaigai |
---|---|
Тема | Re: asynchronous and vectorized execution |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F8011F0224@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | Re: asynchronous and vectorized execution (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: asynchronous and vectorized execution
|
Список | pgsql-hackers |
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of David Rowley > Sent: Tuesday, May 10, 2016 2:01 PM > To: Kaigai Kouhei(海外 浩平) > Cc: Robert Haas; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] asynchronous and vectorized execution > > 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. In GCC 4.8.5, the case label between T_ResultState and T_LimitState were handled using jump table. TupleTableSlot * ExecProcNode(PlanState *node) { : <snip> : switch (nodeTag(node)) 5ad361: 8b 03 mov (%rbx),%eax 5ad363: 2d c900 00 00 sub $0xc9,%eax 5ad368: 83 f8 24 cmp $0x24,%eax 5ad36b: 0f 87 4f 02 00 00 ja 5ad5c0 <ExecProcNode+0x290> 5ad371: ff 24 c5 68 48 8b 00 jmpq *0x8b4868(,%rax,8) 5ad378: 0f 1f 84 00 0000 00 nopl 0x0(%rax,%rax,1) 5ad37f: 00 Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: