pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Noah Misch <noah@leadboat.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [RFC] Removing "magic" oids
Date: Sat, 20 Jul 2019 11:21:52 -0700
Message-ID: <20190720182152.GB1865623@rfd.leadboat.com> (raw)
In-Reply-To: <20190719171257.urgz76ob753ygxmd@alap3.anarazel.de>
References: <20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de>
	<20181114080152.xkk6coduvfrh4ntr@alap3.anarazel.de>
	<20181115045728.GA1121738@rfd.leadboat.com>
	<20181115050241.exereob7wk3xxewj@alap3.anarazel.de>
	<20181120092004.f3j2znfodallkksn@alap3.anarazel.de>
	<20190707170035.GA1485546@rfd.leadboat.com>
	<20190719171257.urgz76ob753ygxmd@alap3.anarazel.de>

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.





view thread (48+ messages)  latest in thread

Message-ID: <20190720182152.GB1865623@rfd.leadboat.com>
Permalink:  ../20190720182152.GB1865623@rfd.leadboat.com/
Also on:    postgresql.org/message-id/20190720182152.GB1865623@rfd.leadboat.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: noah@leadboat.com, andres@anarazel.de
  Subject: Re: [RFC] Removing "magic" oids
  In-Reply-To: <20190720182152.GB1865623@rfd.leadboat.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox