Re: index-only scans

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: index-only scans
Date: 2011-08-12 03:22:16
Message-ID: CA+TgmobocyaSfdPrYReNTZ+D-1oziAGzt98nA93xzn7G2=9wYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 11, 2011 at 9:44 PM, Greg Sabino Mullane <greg(at)turnstep(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-08-12 04:05:31 our buffer replacement strategy is kind of lame
Previous Message Robert Haas 2011-08-12 03:01:14 Re: psql document fix about showing FDW options