Use LAG for _prev_data

[valentijnscholten]

Would this be an improvement? With the subquery approach there's the risk of having N+1 queries where the LAG might be more efficient?

I don't have any real world data in my pghistory tables yet to test, but I though it might be good to pop the question here.

[wesleykendall]

Without explain/analyze plans over realistic large datasets to show it's more performant, it's unlikely I can approve. I can't tell you if it would be more performant by looking at it unfortunately

[9128305]

I have the same problem: #173 (comment)

[penenkel]

I'm also seeing this behavior.
On a table with 120K rows, the current version with subselect takes about 20 seconds, while the variant with LAG takes 800ms.
--- EDIT ---
It looks like this is not quite as black and white as I initially thought: Apparently the window function can cause a lot of overhead in some situations.
--- EDIT 2 ---
I found another part of the query that overshadows the LAG vs subselect clause. The query I'm currently analyzing is the one that provides the data for the admin list-view of Events, so basically the "main" query of that page.
I found out that, if the ordering of the CTE aligns with the ordering of the primary query, there is a significant speedup. Apparently in that case the limit on the primary query also effects the CTE and the database can avoid building all rows of the CTE.

[9128305]

So I moved to using persistent diffs instead like here: #236