]> granicus.if.org Git - postgresql/commit
Fix efficiency problems in tuplestore_trim().
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 10 Dec 2010 16:33:38 +0000 (11:33 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 10 Dec 2010 16:33:38 +0000 (11:33 -0500)
commit244407a7103498d687c8e4ea96b83044f95f0893
tree0900e71ecee9eb249633f90217be5862a20a1ea3
parent663fc32e26e8df41434d751e2203c1aa410d1916
Fix efficiency problems in tuplestore_trim().

The original coding in tuplestore_trim() was only meant to work efficiently
in cases where each trim call deleted most of the tuples in the store.
Which, in fact, was the pattern of the original usage with a Material node
supporting mark/restore operations underneath a MergeJoin.  However,
WindowAgg now uses tuplestores and it has considerably less friendly
trimming behavior.  In particular it can attempt to trim one tuple at a
time off a large tuplestore.  tuplestore_trim() had O(N^2) runtime in this
situation because of repeatedly shifting its tuple pointer array.  Fix by
avoiding shifting the array until a reasonably large number of tuples have
been deleted.  This can waste some pointer space, but we do still reclaim
the tuples themselves, so the percentage wastage should be pretty small.

Per Jie Li's report of slow percent_rank() evaluation.  cume_dist() and
ntile() would certainly be affected as well, along with any other window
function that has a moving frame start and requires reading substantially
ahead of the current row.

Back-patch to 8.4, where window functions were introduced.  There's no
need to tweak it before that.
src/backend/utils/sort/tuplestore.c