Revert "Merge pull request #1732 from VoltDB/ENG-7018-limit-rows-execute-ee"


This reverts commit 7c7f8723538e5c891bd2fbcbd6179d0be7c1e0ee, reversing
changes made to 0ca73a8cc1d7ec5b6c0eae8483a9464137f63577.

This seems to have caused a performance regression.  Phil has confirmed that this revert addresses it.

(Still murky as to why this would cause the slowdown)
I also added an unconditional dynamic_cast to the top of `p_execute`.  The
profiler actually showed it took up about 3.6 of execution time of that
function.  But that still doesn't account for 8%.

On Thu, Nov 20, 2014 at 2:08 PM, Xin Jia <notifications@github.com> wrote:

> In src/ee/executors/insertexecutor.cpp:
>
> > -
> > -                if (!persistentTable->updateTupleWithSpecificIndexes(existsTuple, tempTuple,
> > -                        persistentTable->allIndexes())) {
> > -                    VOLT_INFO("Failed to update existsTuple from table '%s'",
> > -                            persistentTable->name().c_str());
> > -                    return false;
> > -                }
> > -
> > -                // This is not a real insert, it's an update.
> > -                isRealInsert = false;
> > -            }
> > -        }
> > -
> > -        if (isRealInsert) {
> > -
> > -            if (hasPurgeFragment && !isMultiRowInsert) {
>
> Maybe all these extra boolean checks slow down the EE, but should not be
> so much. Still weird.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/VoltDB/voltdb/pull/1819/files#r20669452>.
>



-- 
Chris Wolff, Software Engineer
*VoltDB, Inc.*
*E:* cwolff@voltdb.com

*voltdb.com* <http://www.voltdb.com>
Follow VoltDB  <https://twitter.com/VoltDB>
<https://www.facebook.com/VoltDB>  <https://www.linkedin.com/company/voltdb>