| From: | Doug Doole <dougdoole(at)gmail(dot)com> | 
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Improving executor performance | 
| Date: | 2016-11-04 22:25:58 | 
| Message-ID: | be2aa0e9-81b9-6510-b2ad-28a21a9580aa@gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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). 
Running in our full environment highlighted a few areas that I think are 
worth more investigation.
However, before I tackle that, is the posted proof-of-concept still the 
latest and greatest? If not, any chance of getting the latest?
Going forward, I'd like to collaborate on our efforts if you're interested.
- Doug Doole
Salesforce
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-11-04 23:07:15 | Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 | 
| Previous Message | Tom Lane | 2016-11-04 21:28:09 | Re: Fix bug in handling of dropped columns in pltcl triggers |