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
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) |