Slow Postgres Aggregate Query
There is nothing obviously wrong with the plan, so there is no obvious large optimization to be done. You are fundamentally doing a lot of work, and it takes a lot of time.

I would probably start by taking a step back and looking at your business case.  Why do you need exactly this output?  Could you perhaps "need" something easier to optimize?  Like, something where chunks slide past in their entirety, rather than individual rows slowly passing from chunk to chunk on their way oblivion?  Or maybe where partitions are defined by predictable timestamp slices, rather than as having exactly 1000 rows per partition?

You didn't give your version, but your fiddle uses 9.5.  If I use the latest version and turn on JIT (just-in-time) compilation, I get about a 15% improvement over JIT off.

If I build an index suitable for index only scans, I don't get much improvement, it is sometimes faster and sometimes slower (it also interacts with JIT).  But if everything were not in already memory, it might give a huge improvement:

create index  on measurements (device_id, process_id, timestamp, current);


If you are looking for more complex solutions, you could write a process which will connect to the database and LISTENs for new INSERTs, then updates the data by sliding rows out of one partition and into the next one using incremental calculations, rather than recomputing each partition from scratch.  This is similar to how moving aggregate works, except that that only works between frames within a statement, not between statements like you need. This should be very fast.  For strict accuracy, this would depend on each inserted row committing in the same order of their timestamp column--that requirement is hard to guarantee in general, but might be easy for your exact situation.