Re: Reducing expression evaluation overhead
От | Sailesh Krishnamurthy |
---|---|
Тема | Re: Reducing expression evaluation overhead |
Дата | |
Msg-id | mjq4qso69xd.fsf@cs.berkeley.edu обсуждение исходный текст |
Ответ на | Re: Reducing expression evaluation overhead (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: