Re: Reducing expression evaluation overhead - Mailing list pgsql-hackers

From Sailesh Krishnamurthy
Subject Re: Reducing expression evaluation overhead
Date
Msg-id mjq4qso69xd.fsf@cs.berkeley.edu
Whole thread Raw
In response to Re: Reducing expression evaluation overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
   Tom> The idea I was toying with is to generate, not "x = y" with   Tom> repeated copies of x, but "placeholder = y"
whereplaceholder   Tom> is a dummy expression tree node.  Then at runtime, the CASE   Tom> code would evaluate the test
expressiononce and save it into   Tom> the econtext so the dummy node(s) could regurgitate that   Tom> value.  We
alreadyhave exactly such a mechanism in place to   Tom> handle the VALUE keyword for domain check constraints; it'd
Tom>be easy to duplicate it for CASE.
 

That is exactly what I was proposing. I implemented something like
this in TCQ and used a Const expression tree node. This was for
something we call "grouped filters" where we build an index on
predicates from multiple queries. So if you have a bunch of queries
(say ~1000) each with a predicate "R.a ??? xxx" where ??? is one of
<.>.<=,>=,= then we evaluate using the predicate index which queries
fail for each incoming tuple. 

In a separate experiment we found that ExecEvalVar is particularly
expensive for us .. this is because we have an IntermediateHeapTuple
data structure to represent join tuples (in our framework, join orders
are not fixed) .. the IHT has a set of pointers to the constituent
tuples. This means that we have to do more work in ExecEvalVar
.. essentially one more lookup into the IHT. All this was only
possible because you guys kept around the varnoold and the attnoold !!

-- 
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Custom format for pg_dumpall
Next
From: Dave Cramer
Date:
Subject: Re: Some one deleted pg_database entry how to fix it?