On Fri, Jul 19, 2019 at 10:12:57AM -0700, Andres Freund wrote: > On 2019-07-07 10:00:35 -0700, Noah Misch wrote: > > +# Test concurrent OID generation via pg_enum_oid_index. This indirectly > > +# exercises LWLock and spinlock concurrency. > > +my $labels = join ',', map { "'l$_'" } 1 .. 1000; > > pgbench( > > '--no-vacuum --client=5 --protocol=prepared --transactions=25', > > 0, > > [qr{processed: 125/125}], > > [qr{^$}], > > - 'concurrent insert workload', > > + 'concurrent OID generation', > > { > > '001_pgbench_concurrent_insert' => > > - 'INSERT INTO insert_tbl SELECT FROM generate_series(1,1000);' > > + "CREATE TYPE pg_temp.e AS ENUM ($labels); DROP TYPE > > pg_temp.e;" > > }); > > Hm, perhaps we should just do something stupid an insert into a catalog > table, determining the oid to insert with pg_nextoid? That ought to be a > lot faster and thus more "stress testing" than going through a full > blown DDL statement? But perhaps that's just too ugly.
I expect the pg_nextoid strategy could have sufficed. The ENUM strategy wastes some time parsing 1000 label names, discarding odd-numbered OIDs, and dropping the type. The pg_nextoid strategy wastes time by performing the insertion loop in the executor instead of dedicated C code of EnumValuesCreate(). Hard to say how to weight those factors.