]> 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:35:14 +0000 (11:35 -0500)
commit14a58a1c954103c376754d485e26455dec466c9b
treebeb92000cc3457fa4437cfaf29657703104be56d
parenta804a23e7af0e075b88e7b03bfd9b0f22d2657b2
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