Skip site navigation (1) Skip section navigation (2)

Re: Extensible executor nodes for preparation of SQL/MED

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensible executor nodes for preparation of SQL/MED
Date: 2010-10-26 09:23:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Here is a WIP patch to extensible executor nodes.

It replaces large switch blocks with function-pointer calls (renamed to
PlanProcs from VTable). It has small performance win (Please test it!)
and capsulize some details of executor nodes, but is not perfect.

The infrastructure might be used by SQL/MED, but then not only PlanState
but also Plan and Path are required to be customizable. Complete cleanup
would be difficult, but I'm trying to find common ground for existing
postgres' implementation and extensible planner and executor.
Comments and suggestions welcome.

On Tue, Oct 26, 2010 at 12:21 PM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> I didn't intend performance, but there is small but measurable win
> in it if I avoided indirections. We might not always need to copy
> a whole vtable into planstate; only ExecProcNode might be enough.
> I'll continue the research.
> 24957.767 ms : master (a big switch)
> 25059.838 ms : two indirections (planstate->plan->vtable->fn)
> 24819.298 ms : one indirection (planstate->plan->vtable.fn)
> 24118.436 ms : direct call (planstate->vtable.fn)
> So, major benefits of the change might be performance and code refactoring.
> Does anyone have comments about it for the functionality? It might also be
> used by SQL/MED and executor hooks, but I have no specific idea yet.

Itagaki Takahiro

Attachment: extensible_execnodes-20101026.patch.gz
Description: application/x-gzip (12.6 KB)

In response to


pgsql-hackers by date

Next:From: Dean RasheedDate: 2010-10-26 11:35:13
Subject: Re: Tab completion for view triggers in psql
Previous:From: GregDate: 2010-10-26 08:24:54
Subject: Re: Composite Types and Function Parameters

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group