Re: Improving executor performance - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Improving executor performance
Date
Msg-id 20161108112053.jx7eilyhqdcprfrx@alap3.anarazel.de
Whole thread Raw
In response to Re: Improving executor performance  (Doug Doole <dougdoole@gmail.com>)
List pgsql-hackers
Hi,

On 2016-11-04 15:25:58 -0700, Doug Doole wrote:
> On 07/13/2016 06:18 PM, Andres Freund wrote:
> > Attached (in patch 0003) is a proof-of-concept implementing an
> > expression evalution framework that doesn't use recursion. Instead
> > ExecInitExpr2 computes a number of 'steps' necessary to compute an
> > expression. These steps are stored in a linear array, and executed one
> > after another (save boolean expressions, which can jump to later steps).
> > E.g. to compute colname = 1 the steps are 1) fetch var, 2) evaluate
> > const, 3) call function.
>
> We've been having trouble with the performance of simple expressions in
> PLpgSQL so I started playing with this patch. (No sense re-inventing the
> wheel after all.) It was straightforward to extend to simple expressions and
> showed an immediate improvement (~10% faster on a simple test).

That's cool.


> Running in our full environment highlighted a few areas that I think
> are worth more investigation.

There indeed should be many of those.


> However, before I tackle that, is the posted proof-of-concept still the
> latest and greatest? If not, any chance of getting the latest?

It's definitely *not* the latest and greatest. My latest version
actually passes all regression tests, and has a few additional
expression types handled natively (NULL tests, CASE IIRC), and more than
few bugs fixed.

I'm away at the moment, but I plan to post a new version end of this or
beginning of next week.


> Going forward, I'd like to collaborate on our efforts if you're interested.

That sounds good!

Regards,

Andres



pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Radix tree for character conversion