-
Ole John Aske authored
The SCAN_FRAGREQ signal could possibly become very large when it contains lots of index bounds in the keyInfo part. There is a hard limit on ~32K for signals sent in a single chunk. In order to overcome this limitation for huge SCAN_FRAGREQ, it could be sent as a fragmented signal. This patch change the SPJ block to use sendFragmentedSignal() for sending SCAN_FRAGREQ. As the SPJ block may also send the same SCAN_FRAGREQ to multiple LQHs, it does not want the sent signal data to be released after send (which is the normal behaviour). Thus, sendFragmentedSignal() has been extended to take a 'noRelease' argument to support the reuse of the send signal data. Note: most of the underlying framework to support this was already implemented in SimulatedBlock. As a set of ranges defined for an index scan might now become > 64K, we also had to change the struct RangeBuilder member m_range_size from an Uint16 -> Uint32.
Ole John Aske authoredThe SCAN_FRAGREQ signal could possibly become very large when it contains lots of index bounds in the keyInfo part. There is a hard limit on ~32K for signals sent in a single chunk. In order to overcome this limitation for huge SCAN_FRAGREQ, it could be sent as a fragmented signal. This patch change the SPJ block to use sendFragmentedSignal() for sending SCAN_FRAGREQ. As the SPJ block may also send the same SCAN_FRAGREQ to multiple LQHs, it does not want the sent signal data to be released after send (which is the normal behaviour). Thus, sendFragmentedSignal() has been extended to take a 'noRelease' argument to support the reuse of the send signal data. Note: most of the underlying framework to support this was already implemented in SimulatedBlock. As a set of ranges defined for an index scan might now become > 64K, we also had to change the struct RangeBuilder member m_range_size from an Uint16 -> Uint32.
Loading