Re: [HACKERS] WIP: Faster Expression Processing v4 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] WIP: Faster Expression Processing v4
Date
Msg-id 20170313080351.4g5oubxcj4xj5y7t@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] WIP: Faster Expression Processing v4  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: [HACKERS] WIP: Faster Expression Processing v4
Re: [HACKERS] WIP: Faster Expression Processing v4
Re: [HACKERS] WIP: Faster Expression Processing v4
List pgsql-hackers
Hi,

On 2017-03-12 05:40:51 +0100, Tomas Vondra wrote:
> I wanted to do a bit of testing and benchmarking on this, but 0004 seems to
> be a bit broken.

Well, "broken" in the sense that it's already outdated, because other
stuff that got merged.


> The patch does not apply anymore - there are some conflicts
> in execQual.c, but I think I fixed those. But then I ran into a bunch of
> compile-time errors, because some of the executor nodes still reference bits
> that were moved elsewhere.

Updated patch attached.  Note that this patch has two changes I've not
yet evaluated performance-wise.


Questions:
- New code calls UpdateDomainConstraintRef at the beginning of
  expression evaluation, not for each row.  That allows to generate
  "proper programs" for constraint checking, which is quite useful for
  performance.  But it's a behaviour change.
- I have *not* changed that, but I'm less than convinced of the pattern
  of "runtime" get_cached_rowtype calls.

Changes:
- comments
- fix minor bug in BooleanTest brought to ligth thanks to the new
  regression tests (No, IS TRUE isn't the same IS NOT FALSE)
- fix (theoretical?) issue with get_cached_rowtype() being called once
  for deforming and once for forming a tuple for FieldStores.
- fixed/implemented an optimization XXX around bool AND/OR because the
  solution actually makes the code easier.

What's basically missing here is:
- pgindent run and minimizing resulting damage
- A higher level explanation of how the interpreted expression
  evaluation works.  This patch implements "fairly standard" approach,
  but it's imo sufficiently
- There's one remaining FIXME that needs to be fixed.
- I sometimes see a minor performance regression (~1.2%) in tpch-h's Q17
  that might or might not be code layout related.
- continue pass to ensure all worthwhile comments from execQual.c are
  retained.

Could be delayed:
- add regression tests for track_functions - I've manually verified it
  works, and we previously didn't have tests either.

Greetings,

Andres Freund

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Rafia Sabih
Date:
Subject: Re: [HACKERS] WIP: [[Parallel] Shared] Hash
Next
From: Prabhat Sahu
Date:
Subject: Re: [HACKERS] increasing the default WAL segment size