Re: index-only scans
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Greg Sabino Mullane <greg@turnstep.com>
Cc: pgsql-hackers@postgresql.org
Date: 2011-08-12T03:22:16Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Reduce the alignment requirement of type "name" from int to char, and arrange
- 5f6f840e93a3 8.4.0 cited
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