Postgres中的物化节点之sort节点

顾名思义，物化节点是一类可缓存元组的节点。在执行过程中，很多扩展的物理操作符需要首先获取所有的元组后才能进行操作(例如聚集函数操作、没有索引辅助的排序等)，这时要用物化节点将元组缓存起来。下面列出了PostgreSQL中提供的物化节点。

物化节点概述

物化节点需要有元组的缓存结构，以加快执行效率或实现特定功能(例如排序等)。物化节点的功能种类多样，实现过程也不尽相同，缓存的方式也有所不同，主要使用了 tuplestore来进行缓存。tuplestore使用Tuplestorestate数据结构

//src/backend/utils/sort/tuplestore.c
/*
 * Private state of a Tuplestore operation.
 */
struct Tuplestorestate
{

    TupStoreStatus status;      /* enumerated value as shown above */
    ...
    BufFile    *myfile;         /* underlying file, or NULL if none */
    ...
    void       *(*copytup) (Tuplestorestate *state, void *tup);

    void        (*writetup) (Tuplestorestate *state, void *tup);
    void       *(*readtup) (Tuplestorestate *state, unsigned int len);
    
    void      **memtuples;      /* array of pointers to palloc'd tuples */
    ...

};

来存储相关信息和数据，以上列举了比较重要的字段。status表明了Tuplestore操作期间的状态(保持在内存等待处理；读；写)。memtuples字段指定了一块内存区域用于缓存数据，而当内存中缓存的元组达到一定的数量时会将元组写人myfile字段指定的临时文件。一些函数指针指向了针对该缓存元组的操作函数，浓浓的面向对象的味道。

tuplestore 通过 tuplestore_begin_heap 来构造和初始化，通过 tuplestore_end 进行释放。tuplestore_puttuple函数用于将加人到tuplestore,而tuplestore_gettuple函数则可以从tuplestore中获取元组。
以上可以说是物化节点的基础模板操作流程，几乎所有的物化节点都遵循这一操作流程。下面要说的Sort节点也不例外。

---

Sort节点

Sort节点(排序节点)用于对于下层节点的输出结果进行排序，该节点只有左子节点。排序节点先将下层节点返回的所有元组缓存起来，然后进行排序。由于缓存结果可能很多，因此不可避免地会用到临时文件进行存储，这种情况下Sort节点将使用外排序方法。
Sort节点的定义如下所示，

typedef struct Sort
{
    Plan        plan;
    int         numCols;        /* number of sort-key columns */
    AttrNumber *sortColIdx;     /* their indexes in the target list */
    Oid        *sortOperators;  /* OIDs of operators to sort them by */
    Oid        *collations;     /* OIDs of collations */
    bool       *nullsFirst;     /* NULLS FIRST/LAST directions */
} Sort;

其中保存了进行排序的属性个数(mumCols)、用于排序的属性的厲性号数组(sortcolIdx,长度为numCols)和用于每个排序属性的排序操作符OID数组(sortOperators,长度也为numCols)。另外，Sort节点用一个布尔类型的宇段millsFirst记录是否将空值排在前面。

由于Sort节点仅对元组进行排序，不需要做投影和选择操作，因此在Sort节点的初始化过程(ExecInitSort函数)中不会对Plan结构中的投影(targetlist)和选择(qual)链表进行初始化，只需构造SortState节点并调用下层节点的初始化过程。

typedef struct SortState
{
    ScanState   ss;             /* its first field is NodeTag */
    bool        randomAccess;   /* need random access to sort output? */
    bool        bounded;        /* is the result set bounded? */
    int64       bound;          /* if bounded, how many tuples are needed */
    bool        sort_Done;      /* sort completed yet? */
    bool        bounded_Done;   /* value of bounded we did the sort with */
    int64       bound_Done;     /* value of bound we did the sort with */
    void       *tuplesortstate; /* private state of tuplesort.c */
    int     eflags;                 /* node's capability flags to use sortadaptor */
} SortState;

在SortState中，比较重要的是tuplesortstate字段。在tuplestore的基础之上，PostgreSQL提供了 tuplesortstore (由数据结构Tuplesortstate实现)，它在tuplestore内增加了排序功能：当获取所有的元组后，可对元组进行排序。如果没有使用临时文件，则使用快速排序，否则将使用归并法进行外排序。

而其中LogicalTapeSet类型的字段则提供了在外部排序时的排序文件的功能(类似于Tuplestorestate中的BufFile字段)。

下面老规矩，对着代码我们细说。

首先，Sort节点的执行入口是：

TupleTableSlot *
ExecSort(SortState *node)

它被上层的ExecProcNode函数调用，输出元组。

在ExecSort函数的首次调用中会首先通过tuplesort_begin_heap对元组缓存结构初始化，返回一个Tuplesortstate结构。

Tuplesortstate *
tuplesort_begin_heap(TupleDesc tupDesc,
                     int nkeys, AttrNumber *attNums,
                     Oid *sortOperators, Oid *sortCollations,
                     bool *nullsFirstFlags,
                     int workMem, bool randomAccess)

随后针对是否存在limit字段设置返回元组的bound数以及其它的一些flags。

然后循环执行下层节点获取元组，循环执行调用tuplesort_puttupleslot函数。

void
tuplesort_puttupleslot(Tuplesortstate *state, TupleTableSlot *slot)

该函数主要是

• 1.将获得的元组进行拷贝(考虑到内存上下文的问题，必须拷贝而不是引用)，
• 2.调用puttuple_common函数进行共通处理。

puttuple_common函数比较微妙，会根据Sort节点所在的状态做不同处理。

其实说白了就是依据当前已输入元组的数量决定排序的方法：

• 1.数据量少到可以整体放到内存的话，就直接快速排序走起；
• 2.数据量较大内存放不下，但是所需要返回的元组内存可以装下或者TOP N的性能比快排好的话，TOP N类型的算法走起(这里是堆排序)，；
• 3.数据量很大，并且返回的元组内存也放不下的话，外部归并排序走起。

下面是楼主自己简化理解：

switch (status)
{
    case TSS_INITIAL:(这个状态下暂时是快速排序)
        读入SortTuple；
        满足  if (state->bounded &&
                (state->memtupcount > state->bound * 2 ||
                 (state->memtupcount > state->bound && LACKMEM(state))))：
            则switch over to a bounded heapsort(大顶堆)
            status = TSS_BOUNDED    -->堆排序

        if (state->memtupcount < state->memtupsize && !LACKMEM(state))
            return;返回, -->快速排序
        否则Execute_Tape_sort：
            将数据写到tape  
            status = TSS_BUILDRUNS-->外部归并排序
            
    case TSS_BOUNDED:(这个状态下已经是堆排序)
        if new tuple <= top of the heap, so we can discard it
        else discard top of heap, sift up, insert new tuple
        
    case TSS_BUILDRUNS:(这个状态下已经是外部归并排序)
        Insert the tuple into the heap, with run number currentRun if
        it can go into the current run, else run number currentRun+1.
}

获取到下层节点的所有元组之后，调用tuplesort_performsort对缓存元组进行排序(这里就根据status的值来确定使用哪一种排序方法)。

然后输出第一个元组。

第一次调用到此结束。

后续对Sort节点的执行都将直接调用tuplesort_gettupleslot从缓存中返回一个元组。比如说你要返回100个元组，这里就要重复执行1+99(这个1是最开始的第一次)次得到结果。

我们也来看看上层怎么调用的吧。我们假设一个简单的语句和它的查询计划：

postgres=# explain select  id,xxx  from test order by id ;

                              QUERY PLAN
----------------------------------------------------------------------
 Sort  (cost=2904727.34..2929714.96 rows=9995048 width=34)
   Sort Key: id
   ->  Seq Scan on test  (cost=0.00..376141.48 rows=9995048 width=34)
(3 行)

查询编译阶段我就不说了，我们直接到查询执行。
这里应该是进入到了standard_ExecutorRun函数：

void
standard_ExecutorRun(QueryDesc *queryDesc,
                     ScanDirection direction, long count)

这个函数只是一个壳子，根据提供的查询描述符QueryDesc做一些初始化操作，设置好内存上下文之后，把工作交给ExecutePlan函数来做。
ExecutePlan函数也是个壳子，里面包着这个死循环，循环一次就执行一次计划节点。再看上面的查询计划。对应到这里就是首先执行planstate中最上层的Sort节点，而Sort节点又会循环地调用Scan节点来获取元组(上面已经提到)。整体就是一个循环递归的过程。

    /*
     * Loop until we've processed the proper number of tuples from the plan.
     */
    for (;;)
    {
        /* Reset the per-output-tuple exprcontext */
        ResetPerTupleExprContext(estate);

        /*
         * Execute the plan and obtain a tuple
         */
        slot = ExecProcNode(planstate);

        /*
         * if the tuple is null, then we assume there is nothing more to
         * process so we just end the loop...
         */
        if (TupIsNull(slot))
            break;
    ...
    }

Sort节点的清理过程(ExecEndSort函数)需要调用tuplesort_end对缓存结构进行清理回收，然后调用下层节点的清理过程。
整个查询执行周期里的节点的生死的函数调用栈如下：

初始化
standard_ExecutorStart
    ---->InitPlan
        ---->ExecInitNode
            ---->ExecInitSort
                ---->ExecInitSeqScan
执行              
standard_ExecutorRun                
    ---->ExecutePlan
        ---->ExecProcNode
            ---->ExecSort
                ---->ExecSeqScan
结束
standard_ExecutorEnd                
    ---->ExecEndPlan
        ---->ExecEndNode
            ---->ExecEndSort
                ---->ExecEndSeqScan

强迫症表示一本满足。

tips:调试

postgresql内部给了很多针对性的调试宏和参数，这里记录一下。

在postgresql.conf文件中有一个trace_sort参数可以在日志中打印Sort中的节点的初始化执行和结束信息。

---

小结

本文讲述了postgresql的sort节点的执行过程，也大致说了下基本节点的执行过程，本质就是上层节点递归地调用下层节点的过程。这次讲的比较粗，由于时间紧迫。

2017快完了，还是要多写写。

转载于:https://www.cnblogs.com/flying-tiger/p/8120046.html