The “maxscanrows” setting (which is configured by the admin for each user group) constrains the number of database rows that are scanned by any given query. In the case of
p4 changes, there are two different ways the query might run, depending on the arguments you pass:
- If a path is specified, the
db.reventries matching the path are scanned, and the changelists matching the revision range are selected from that set.
db.revis indexed by path.
- If no path is specified, and if the revision range does not depend on revision data (e.g. dates, which are contained in the changelists themselves),
db.changeentries are scanned in order to locate the ones matching the range.
An exception to (1) is that if a maximum number of changelists is requested,
db.revcx may be used if the path is very broad. This logic can be tuned and is described in
p4 help undoc:
dm.changes.thresh1 50K 'changes -mx path' uses db.revcx if... dm.changes.thresh2 10K ...if < thresh2 of thresh1 db.rev match
For your specific case, I think you will find that:
p4 changes -s submitted @2020/11/03,2020/11/04
performs much faster (and without hitting the maxscanrows limit), because it will search based on
As you noted in your own answer, narrowing the depot path is another possible solution, because that will reduce the number of
db.rev rows scanned — however, this will give you different results (and depending on how much you narrow the depot path, it still may not be as quick as simply scanning the change table).
In order to see which specific tables are accessed by a given query, and how many rows of each are accessed, you can use the
-Zdbstat global flag:
C:\Perforce\test>p4 -Zdbstat changes -s submitted @2019/11/03,2020/11/04 ... --- db.revcx --- pages in+out+cached 1+0+1 --- locks read/write 0/0 rows get+pos+scan put+del 0+0+0 0+0 --- peek count 1 wait+held total/max 0ms+0ms/0ms+0ms ... --- db.change --- pages in+out+cached 5+0+4 --- locks read/write 0/0 rows get+pos+scan put+del 0+1+127 0+0 --- peek count 1 wait+held total/max 0ms+0ms/0ms+0ms ...
C:\Perforce\test>p4 -Zdbstat changes -s submitted //[email protected]/11/03,2020/11/04 ... --- db.rev --- pages in+out+cached 27+0+26 --- locks read/write 0/0 rows get+pos+scan put+del 0+1+868 0+0 --- peek count 1 wait+held total/max 0ms+16ms/0ms+16ms ... --- db.change --- pages in+out+cached 4+0+3 --- locks read/write 0/0 rows get+pos+scan put+del 0+64+128 0+0 --- peek count 1 wait+held total/max 0ms+0ms/0ms+0ms ...
This can be a very helpful tool in tuning queries for efficiency in cases like this where you have multiple ways to get at a particular piece of data, and especially in understanding why you’re bumping into specific performance limits.
CLICK HERE to find out more related problems solutions.