mirror of
https://github.com/postgres/postgres.git
synced 2025-07-08 11:42:09 +03:00
In the executor, use an array of pointers to access the rangetable.
Instead of doing a lot of list_nth() accesses to es_range_table, create a flattened pointer array during executor startup and index into that to get at individual RangeTblEntrys. This eliminates one source of O(N^2) behavior with lots of partitions. (I'm not exactly convinced that it's the most important source, but it's an easy one to fix.) Amit Langote and David Rowley Discussion: https://postgr.es/m/468c85d9-540e-66a2-1dde-fec2b741e688@lab.ntt.co.jp
This commit is contained in:
@ -2484,9 +2484,8 @@ CopyFrom(CopyState cstate)
|
||||
estate->es_result_relations = resultRelInfo;
|
||||
estate->es_num_result_relations = 1;
|
||||
estate->es_result_relation_info = resultRelInfo;
|
||||
estate->es_range_table = cstate->range_table;
|
||||
estate->es_relations = (Relation *) palloc0(list_length(cstate->range_table) *
|
||||
sizeof(Relation));
|
||||
|
||||
ExecInitRangeTable(estate, cstate->range_table);
|
||||
|
||||
/* Set up a tuple slot too */
|
||||
myslot = ExecInitExtraTupleSlot(estate, tupDesc);
|
||||
|
Reference in New Issue
Block a user