On Wed, 3 Aug 2005, Tom Lane wrote:
> I seem to recall having thought of this idea before, and having rejected
> it as being too much overhead to solve a problem that occurs only rarely
> --- but in a quick test involving many repetitions of
>
> create temp table t1(f1 int, f2 int);
> drop table t1;
>
> the net penalty was only about a 2% slowdown on one machine, and no
> measurable difference at all on another. So it seems like it might
> be worth doing.
>
> Comments?
Looks good. Another approach would be to put the existing code in a
PG_TRY() block and catching the duplicate key violation. This is more
optimistic in that we only wear the systable scan(s) when we encounter a
problem. The issue is distinguishing between a duplicate key violation
caused by the OID and a violation due, say, to a duplication
table/namespace entry. We catch that further up the code path at the
moment but it isn't future proof.
The fact that there is little measurable differences suggests that your
solution is fine, though.
Thanks,
Gavin