Re: Solving the OID-collision problem

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Solving the OID-collision problem
Date: 2005-08-04 00:48:44
Message-ID: Pine.LNX.4.58.0508041042030.14621@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-08-04 00:55:04 Re: Solving the OID-collision problem
Previous Message Andrew Dunstan 2005-08-04 00:34:20 Re: US Census database (Tiger 2004FE)