On Thu, Aug 11, 2011 at 9:44 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:
>>> Maybe it's time to finally remove the been-deprecated-for-a-while OIDs?
>
>> I thought about just not supporting that for index-only scans, but
>> system catalogs use them pretty extensively, and it doesn't seem out
>> of the question that that could matter to people who have lots of SQL
>> objects floating around.
>
> Right - when I said remove, I meant for all but system catalogs. I
> would think those are generally small enough that for most people
> the lack of index-only scans on those would not matter. Heck, the
> system catalogs are already "special" in lots of ways other than
> having OIDs (most anyway), so it's not as though we'd be breaking
> sacred ground with an index-only exception. :)
Yeah, maybe. But since there's no evidence that we actually need that
exception for performance, I'm not in favor of adding it at this
point.
> I guess the question that should be asked is "we are going to finally
> remove OIDs someday, right?".
I don't necessarily see a reason to do that. I wouldn't object to
turning the system OID columns in the system catalogs into normal OID
columns, but that would be a lot of work and it doesn't seem to me to
be the most important problem we need to solve (or even in the top
25).
> If so, and if it's potentially blocking a
> major new feature, why not now?
It's not blocking a major new feature, except to the extent that we're
having a conversation about it, instead of talking about the major new
feature.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company