Fixed 1000‑Entry Page Size vs. Tunable Page Size for Large Pacman Queries

Direct answer

Do not add a tunable page size to pacman yet. Add it only if profiling shows the fixed page-size constant is the actual memory driver for your large query. If a tunable option is justified, an initial default of roughly 100 to 200 entries is a reasonable starting balance between peak memory and pager overhead, but it is not a confirmed optimum for all Arch workloads.

Likely explanation versus confirmed facts

Likely explanation (unverified): a fixed page causes pacman to hold an entire page of package metadata in memory before display. Peak RSS should scale with entry count multiplied by average record size, so long descriptions and locale conversion can amplify memory use. Smaller pages reduce peak memory and time to first screen but increase pager invocations and context switches; larger pages reduce pager overhead but raise peak memory.

Confirmed facts: pacman is a C package manager that reads package database records. Whether a <code>--paginate</code> option with a hard-coded 1000-entry limit exists in your installed version is version-dependent and not established by this brief. High memory may also come from description loading, locale conversion, or pager buffering rather than the page-size constant.

Verification steps for this case

1. Confirm the option exists on the target system: <code>man pacman</code> and <code>pacman -h | grep -i paginate</code>
2. Measure peak RSS for a representative large query: <code>/usr/bin/time -v pacman -Qs <term></code> under the current pager, then compare across terminal sizes.
3. Inspect pacman source for the page-size constant and query-result buffering path before writing a patch.
4. Test any proposed default on a representative package database and typical terminal before changing packaged defaults.

Missing diagnostic detail

Provide measured peak RSS, entry count, and average description size for the failing pacman query. This detail changes the recommendation because it determines whether page size, rather than description loading or pager buffering, is responsible for the high memory consumption.

Assumptions and uncertainty: this draft treats the 1000-entry limit and <code>--paginate</code> behavior as unconfirmed for your pacman version. Treat the 100 to 200 entry default as a planning estimate, not a benchmarked result.