A recent article introduced partitioned B-trees, in which partitions are defined not in the catalogs but by distinct values in an artificial leading key column. As there usually is only a single value in this column, there usually is only a single partition, and queries and updates perform just like in traditional B-tree indexes. By temporarily permitting multiple values, at the expense of reduced query performance, interesting database usage scenarios become possible, in particular for bulk insert (database load). The present paper guides database administrators to exploiting partitioned B-trees even if they are not implemented by their DBMS vendor.