Re: [HACKERS] Remove pg_am.amindexnulls?
On Fri, Jan 7, 2011 at 11:41 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remove pg_am.amindexnulls?
Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remove pg_am.amindexnulls?
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 da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remove pg_am.amindexnulls?
David Fetter da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remove pg_am.amindexnulls?
On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane t...@sss.pgh.pa.us wrote: David Fetter da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Remove pg_am.amindexnulls?
Robert Haas robertmh...@gmail.com writes: On Fri, Jan 7, 2011 at 8:20 PM, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
