Re: index-only scans
От | Robert Haas |
---|---|
Тема | Re: index-only scans |
Дата | |
Msg-id | CA+TgmobocyaSfdPrYReNTZ+D-1oziAGzt98nA93xzn7G2=9wYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: index-only scans ("Greg Sabino Mullane" <greg@turnstep.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: