David Rowley <david.rowley@2ndquadrant.com> writes:
> I also did some more benchmarking of the patch. ...
> Which makes the patched version 2.2% faster than master on that run.
BTW, further on the subject of performance --- I'm aware of at least
these topics for follow-on patches:
* Fix places that are maintaining arrays parallel to Lists for
access-speed reasons (at least simple_rte_array, append_rel_array,
es_range_table_array).
* Look at places using lcons/list_delete_first to maintain FIFO lists.
The patch makes these O(N^2) for long lists. If we can reverse the list
order and use lappend/list_truncate instead, it'd be better. Possibly in
some places the list ordering is critical enough to make this impractical,
but I suspect it's an easy win in most.
* Rationalize places that are using combinations of list_copy and
list_concat, probably by inventing an additional list-concatenation
primitive that modifies neither input.
* Adjust API for list_qsort(), as discussed, to save indirections and
avoid constructing an intermediate pointer array. I also seem to recall
one place in the planner that's avoiding using list_qsort by manually
flattening a list into an array, qsort'ing, and rebuilding the list :-(
I don't think that any one of these fixes would move the needle very
much on "typical" simple workloads, but it's reasonable to hope that in
aggregate they'd make for a noticeable improvement. In the meantime,
I'm gratified that the initial patch at least doesn't seem to have lost
any ground.
regards, tom lane
