How a run is paged

A run does not read its whole window in one go. It reads in pages. Most tasks never
need this touched, but paging decides how much a run holds at once, and on a long
backfill that is the difference between a task that finishes and one that does not.

The settings

The event counts live on the General tab, under Throughput, not on Time Alignment,
where they left no room for the key-channel picker in Keys mode. They decide how much is
fetched or written per call, never which values exist.

Setting	What it controls	Default
Page read event count	Events per read page	100,000
Page write event count	Events per write page	10,000
Request event count	Inner chunk for the aligned modes	10,000

Writing is batched only: the write count changes how many calls a run makes, never which
values it writes. The request count applies to Interval and Keys, where the timeline is
built first and values are fetched onto it.

The read page default is also a hard ceiling. A read page is one call, and for a
remote source that call is a single message on the bus. Oversized payloads are refused
outright, so a larger page is a broken read rather than a slow one. The floor is 1,000.
Values outside the range are clamped when the task runs, not rejected when you save.

The budget is shared across everything on a connection

One read serves every variable on a connection in a single call, so the page size is a
budget for the whole call, divided by the number of distinct objects in it.

Two channels on one connection with a page size of 100,000 get 50,000 events each,
not 100,000 each. Distinct objects are what count, so two variables pointing at the
same tag count once.

If enough objects share a connection that the divided page falls below 1,000, the run
logs a warning. Reads simply happen more often: chatty rather than broken.

Where a page actually ends

Not at the requested end time, and not at a round number of events. A page ends at
the oldest last-event timestamp among the variables that filled their page.

An example. A window of 00:00–06:00, two channels, 50,000 events each per page:

• x1 has 10,000 events in the window, so it comes back short: its page did not fill,
  and it gets no say in where the page ends.
• x2 has 200,000 events, so its page fills, and its 50,000th event falls at 02:30.
• The page therefore ends at 02:30, and every variable is trimmed to 02:30: x1's
  events after that point are dropped from this page.
• The next page restarts every variable just after 02:30.

The trimming keeps the variables aligned. If x1 ran ahead to 06:00 while x2 had only reached
02:30, the merge modes would emit rows pairing fresh x1 values with stale x2 ones.
Every variable covering the same span per page is what prevents that.

Two consequences follow:

The densest channel sets the pace. Trimmed data is re-read on the next page, so a
slow channel sitting beside a fast one gets fetched again on every page the fast one
triggers. A task mixing a once-a-minute tag with a ten-a-second tag does more source
reads than either would alone: splitting very different rates into separate tasks is
a real optimisation.

Page boundaries land at data-dependent times. 02:30 above is neither round nor
configurable; it is wherever the busiest channel's page happened to fill.

Paging does not change your results

It would be reasonable to worry that a windowed calculation gets a cold start at every
one of those boundaries. It does not: each page carries the previous page's trailing
events forward in memory as warm-up, and stops emitting one window short of its own end,
leaving that region to the next page. Page size is a performance setting, not a
correctness one.

One exception, on table, JSON and SQL output

A forward-looking window, a plain resample(), still has wrong values at page
boundaries, and nothing in the run says so. Channel calculations are correct in both
directions, and so are table tasks whose window looks backward. If it affects you, raise
page read event count until a page covers more than one window.

When the window is longer than a page

There is one configuration the warm-up cannot cover, and Stream says so loudly rather
than degrading quietly. At Warning level:

page warm-up needs N event(s) but is capped at M; the oldest N-M were dropped.

It means your start offset covers more time than one page reads, so the first window
on the next page is computed on partial history and its result will be wrong. Raise
page read event count so a page spans more than the window, or reduce the start
offset to the window the script actually looks back over.

It takes an unusual combination to reach: an hour-long window over one-minute data needs
120 events against a 100,000 cap.

What's Next

Back to Time Alignment for the mode, or
The offsets for the window's edges.

Related

• Time Alignment: which rows a task produces
• The offsets: where the window starts and stops
• Task Calculation: why a page boundary matters to a windowed script