Date: Mon, 1 Oct 2018 00:15:51 +0200
From: David Fetter <david@fetter.org>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [RFC] Removing "magic" oids
Message-ID: <20180930221551.GA14404@fetter.org>
References: <20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

On Sat, Sep 29, 2018 at 08:48:10PM -0700, Andres Freund wrote:
> Hi,
> 
> In my opinion the current WITH OIDs system has numerous weaknesses:
> 
> 1) The fact that oids are so magic means that if we get pluggable
>    storage, the design of the potential pluggable systems is constrained
>    and similar magic has to be present everywhere.
> 
> 2) The fact that the oids in each table have the same counter to be
>    based on means that oid wraparounds have much worse consequences
>    performance wise than necessary. E.g. once the global counter has
>    wrapped, all toast tables start to be significantly slower.
> 
>    It would be much better if most database objects had their own
>    counters.
> 
> 3) For some oid using objects (toast, large objects at the very least)
>    it'd be quite worthwhile to switch to 8 byte ids.  Currently that's
>    hard to do, because it'd break on-disk compatibility.
> 
> 4) There's a lot of special case code around for dealing with oids.
> 
> 5a) The fact that system table oids don't show up in selects by default
>    makes it more work than necessary to look at catalogs.
> 
> 5b) Similarly, it's fairly annoying when debugging not to trivially see
>    oids for catalog structs.
> 
> 
> I think we should drop WITH OIDs support.

+1

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate