Thread: Remove pg_am.amindexnulls?
Now that GIN can index null items, its amindexnulls flag in pg_am really
ought to be set true. However, looking at the usage of that column,
I wonder whether we shouldn't just delete it instead. The only present
usage is a rather convoluted test in CLUSTER to see if the index is
safely clusterable --- and AFAICS that test has been obsoleted anyhow
by the later addition of pg_am.amclusterable. Anyone against
simplifying matters by getting rid of pg_am.amindexnulls?
regards, tom lane
On Fri, Jan 07, 2011 at 08:08:38PM -0500, Tom Lane wrote: > Now that GIN can index null items, its amindexnulls flag in pg_am > really ought to be set true. However, looking at the usage of that > column, I wonder whether we shouldn't just delete it instead. The > only present usage is a rather convoluted test in CLUSTER to see if > the index is safely clusterable --- and AFAICS that test has been > obsoleted anyhow by the later addition of pg_am.amclusterable. > Anyone against simplifying matters by getting rid of > pg_am.amindexnulls? I guess the only potential use for it would be for some kind of am that *couldn't* index nulls out of the gate. Might their be such AMs on the horizon? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
> On Fri, Jan 07, 2011 at 08:08:38PM -0500, Tom Lane wrote:
>> Anyone against simplifying matters by getting rid of
>> pg_am.amindexnulls?
> I guess the only potential use for it would be for some kind of am
> that *couldn't* index nulls out of the gate. Might their be such AMs
> on the horizon?
Well, there are AMs around already that can't index nulls: hash is one,
and GIN was one until an hour ago. The question though is whether
anything outside the AM needs to know about that behavior. Between
amclusterable, amsearchnulls, and amoptionalkey, I believe that we have
quite enough flags already to cover what anything else actually
needs-to-know about the AM's behavior.
regards, tom lane
On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > David Fetter <david@fetter.org> writes: >> On Fri, Jan 07, 2011 at 08:08:38PM -0500, Tom Lane wrote: >>> Anyone against simplifying matters by getting rid of >>> pg_am.amindexnulls? > >> I guess the only potential use for it would be for some kind of am >> that *couldn't* index nulls out of the gate. Might their be such AMs >> on the horizon? > > Well, there are AMs around already that can't index nulls: hash is one, > and GIN was one until an hour ago. The question though is whether > anything outside the AM needs to know about that behavior. Between > amclusterable, amsearchnulls, and amoptionalkey, I believe that we have > quite enough flags already to cover what anything else actually > needs-to-know about the AM's behavior. I've pretty much come to the conclusion that pg_am is much better at providing the illusion of abstraction than it is at providing actual abstraction. IIUC, the chances that a third-party AM would need to patch core are nearly 100% anyway, so I'm not inclined to spend much mental energy trying to figure out what flags it might hypothetically need. In other words, go nuts. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Between
>> amclusterable, amsearchnulls, and amoptionalkey, I believe that we have
>> quite enough flags already to cover what anything else actually
>> needs-to-know about the AM's behavior.
> I've pretty much come to the conclusion that pg_am is much better at
> providing the illusion of abstraction than it is at providing actual
> abstraction. IIUC, the chances that a third-party AM would need to
> patch core are nearly 100% anyway, so I'm not inclined to spend much
> mental energy trying to figure out what flags it might hypothetically
> need.
Well, I'll grant that allowing loadable modules to emit and replay WAL
records is an unsolved problem, but the existence of that problem
doesn't mean that we should entirely give up on keeping AMs modular.
I believe that they *are* pretty modular except for that one issue.
regards, tom lane
On Fri, Jan 7, 2011 at 11:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Between >>> amclusterable, amsearchnulls, and amoptionalkey, I believe that we have >>> quite enough flags already to cover what anything else actually >>> needs-to-know about the AM's behavior. > >> I've pretty much come to the conclusion that pg_am is much better at >> providing the illusion of abstraction than it is at providing actual >> abstraction. IIUC, the chances that a third-party AM would need to >> patch core are nearly 100% anyway, so I'm not inclined to spend much >> mental energy trying to figure out what flags it might hypothetically >> need. > > Well, I'll grant that allowing loadable modules to emit and replay WAL > records is an unsolved problem, but the existence of that problem > doesn't mean that we should entirely give up on keeping AMs modular. > I believe that they *are* pretty modular except for that one issue. I'm not in a hurry to chuck the current system completely, but it strikes me that the planner basically has to know everything about what the AMs can do. I agree there's some value in encapsulating that behind Booleans, but adding a new AM, or a new feature to an existing AM, can be expected to result in regular rearrangements of those Booleans. So it seems a bit porous. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Tom Lane <tgl@sss.pgh.pa.us> > Now that GIN can index null items, its amindexnulls flag in pg_am really > ought to be set true. However, looking at the usage of that column, > I wonder whether we shouldn't just delete it instead. The only present > usage is a rather convoluted test in CLUSTER to see if the index is > safely clusterable --- and AFAICS that test has been obsoleted anyhow > by the later addition of pg_am.amclusterable. Anyone against > simplifying matters by getting rid of pg_am.amindexnulls? There has been multiple attempts at implementing bitmap indexes in the "recent" past, any impact between that efforts and your change? That's all I can think about and I don't even know how much it's related… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support