1. Redesign Local thread pool Currently, there are some issues with the design of the local thread pool used to execute queries. In this project, a better design should be implemented. To understand the terminology, let's first briefly define a couple terms: Executor: In Tuplex an executor (Executor.cc/.h) is a thread together with a managed memory region (BitmapAllocator.h). Memory is managed in Tuplex in blocks which are called partitions (Partition.cc/.h). Each Partition can be spilled to disk if necessary, which works using LRU (least-recently-used) disk spilling. Any Executor can read any executor's partition, but can only write to a partition which comes from its own memory region (single-writer/multiple reader lock). WorkQueue: A Workqueue is a thread-safe queue where Tasks can be added (Tasks derived from IExecutorTask.cc/.h). To make an Executor work tasks from a WorkQueue, it can get attached/detached from a workqueue (cf. Executor.cc/.h). LocalEngine: Not perfectly named, the LocalEngine is a Singleton which manages the thread-pool. Whenever a new Context is created, either an existing thread/Executor is reused or a new one created if no matching one in the current pool exists. In particular, the current design has the following drawbacks:

# Python3 string function support |string function|support |---|---| |capitalize|no| |casefold|no| |center|no| |count|no| |encode|no| |endswith|no| |expandtabs|no| |find|no| |format|no| |format_map|no| |index|no| |isalnum|no| |isalpha|no| |isascii|no| |isdecimal|no| |isdigit|no| |isidentifier|no| |islower|no| |isnumeric|no| |isprintable|no| |isspace|no| |istitle|no| |isupper|no| |join|no| |ljust|no| |lower|no| |lstrip|no| |maketrans|no| |partition|no| |replace|no| |rfind|no| |rindex|no| |rjust|