Re: [RFC] Removing "magic" oids

On Sat, Jul 20, 2019 at 12:56:34PM -0700, Andres Freund wrote:
> On 2019-07-20 11:21:52 -0700, Noah Misch wrote:
> > 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.
> 
> Fair enough. Are you planning to commit your changes?

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8a0cbb88524e8b6121597285b811640ee793b3e8