Regression in `nexus-db-queries` test performance from user_data_export

[smklein]

While running the nexus-db-queries test suite, I'm noticing that the tests added in this PR have slowed down tests for that module by several minutes - they're the only SLOW tests labelled by nextest, where most other tests are completing in ~5 seconds or less.

        SLOW [> 60.000s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_create_large
        SLOW [> 60.000s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_delete_large
        SLOW [> 60.000s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_noop_large
        SLOW [> 60.000s] nexus-db-queries db::datastore::user_data_export::tests::test_delete_records_for_expunged_pantries
        PASS [ 100.380s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_create_large
        SLOW [>120.000s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_delete_large
        SLOW [>120.000s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_noop_large
        SLOW [>120.000s] nexus-db-queries db::datastore::user_data_export::tests::test_delete_records_for_expunged_pantries
        PASS [ 148.597s] nexus-db-queries db::datastore::user_data_export::tests::test_delete_records_for_expunged_pantries
        PASS [ 151.758s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_noop_large
        SLOW [>180.000s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_delete_large
        SLOW [>240.000s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_delete_large
        PASS [ 266.981s] nexus-db-queries db::datastore::user_data_export::tests::test_changeset_delete_large

I see that there are many tests here running in a loop for a LARGE_NUMBER_OF_ROWS - what is this aiming to test? Is it necessary to actually use an iteration of "3000x" to accomplish this?

Originally posted by @smklein in #8471 (comment)

[jmpesp]

LARGE_NUMBER_OF_ROWS was intended to test that for those queries the query planner wouldn't generate a plan that used full table scans when the number of rows went over some threshold. I don't remember where that number came from but it can certainly come down, and maybe even go away if my mental model is wrong here!

[smklein]

I've seen cockroachdb flag full table scans on tables that contain single-digit numbers of rows - for most of my unit testing, I rarely populate tables with > 5 rows, and still feel like it does a pretty good job if the "disallow_full_table_scans" setting is on (which is the default in Omicron).

Was this not working for your use-case? (If so, I'm the one with the mental model that needs to update!)

[jmpesp]

Tuning that down to 10 in #8978