Thread: enable_constraint_exclusion GUC name
Is enable_constraint_exclusion the proper name for this feature? I know we have enable* in the optimizer settings, but that naming seems unfortunate in that we should have just called it hash_join and it could be enabled/disabled. I am thinking we should just call it constraint_exclusion. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
pgman wrote: > Is enable_constraint_exclusion the proper name for this feature? I know > we have enable* in the optimizer settings, but that naming seems > unfortunate in that we should have just called it hash_join and it could > be enabled/disabled. > > I am thinking we should just call it constraint_exclusion. So, given the silence on this, I assume people think we should rename this before beta starts. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> pgman wrote:
>> Is enable_constraint_exclusion the proper name for this feature? I know
>> we have enable* in the optimizer settings, but that naming seems
>> unfortunate in that we should have just called it hash_join and it could
>> be enabled/disabled.
>>
>> I am thinking we should just call it constraint_exclusion.
> So, given the silence on this, I assume people think we should rename
> this before beta starts.
Or that they think it might as well be left alone. I would like to
think that the parameter will have a very finite lifespan anyway;
if it's still there in 8.2, it'll be because we didn't get cached
plan updating done, and I hope that will not be the case.
regards, tom lane
>> >>I am thinking we should just call it constraint_exclusion. > > > So, given the silence on this, I assume people think we should rename > this before beta starts. Well it depends either one seems correct per the postgresql.conf. For example enable_seqscan, or "add"_missing_from_clause. It seems that if the postgresql.conf parameter is actually causing a different behavior we tend to note the behavior in the prefix (thus enable/add) but that if it is more general we done (thus log_) . I don't care either way but it seemed something to note before the decision was made. Sincerely, Joshua D. Drake > -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Joshua D. Drake wrote: > >> > >>I am thinking we should just call it constraint_exclusion. > > > > > > So, given the silence on this, I assume people think we should rename > > this before beta starts. > > Well it depends either one seems correct per the postgresql.conf. For > example enable_seqscan, or "add"_missing_from_clause. > > It seems that if the postgresql.conf parameter is actually causing a > different behavior we tend to note the behavior in the prefix (thus > enable/add) but that if it is more general we done (thus log_) . > > I don't care either way but it seemed something to note before the > decision was made. I thought about that, but is seems all our booleans could logically fall into the category of being enabled/disabled. For add_missing_from, the add word is so people realize that it is really _adding_ to the FROM list, so I see it as different. Anyway, change committed. I can always change it back if people change their mind. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Greg Stark wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Greg Stark wrote: > > > > > > show_parser_stats true > > > enable_hashjoin true > > > > > > Nouns sound stranger and more awkward: > > > > > > geqo true > > > parser_stats true > > > hashjoin true > > > > Interesting analysis. No verb in there. > > Note that the verb isn't always the same and what verb is chosen helps someone > understand what the server will do. > > show_parser_stats is going to "show" something. > add_missing_from is going to "add" something. > > So what will standards_compliant_strings make the server *do*? > > It's going to ignore backslash escapes. Perhaps the option should be something > like "interpret_nonstandard_string_escapes" or something like that. > > I actually don't really like "interpret" but I can't think of anything else at > the moment. Ah, Peter renamed it to: standard_conforming_strings so what is does is "conform"? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Greg Stark wrote: > > > > show_parser_stats true > > enable_hashjoin true > > > > Nouns sound stranger and more awkward: > > > > geqo true > > parser_stats true > > hashjoin true > > Interesting analysis. No verb in there. Note that the verb isn't always the same and what verb is chosen helps someone understand what the server will do. show_parser_stats is going to "show" something. add_missing_from is going to "add" something. So what will standards_compliant_strings make the server *do*? It's going to ignore backslash escapes. Perhaps the option should be something like "interpret_nonstandard_string_escapes" or something like that. I actually don't really like "interpret" but I can't think of anything else at the moment. -- greg
Greg Stark wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > I thought about that, but is seems all our booleans could logically fall > > into the category of being enabled/disabled. For add_missing_from, the > > add word is so people realize that it is really _adding_ to the FROM > > list, so I see it as different. > > > > Anyway, change committed. I can always change it back if people change > > their mind. > > I suggest that the rule you've been (unconsciously) following is the > following: parameters that form a verb phrase do not need an enable_ prefix. > But parameters that form a noun phrase do or else they sound strange. > > Put another way, "all boolean parameters are verb phrases; if they're not then > turn them into a verb phrase by prepending a verb like `enable'" > > I see a couple exceptions (debug_assertions, geqo) but mostly they seem to > follow this pattern. > > I'm not sure that's a bad rule. Verbs sound nice when you read them: > > show_parser_stats true > enable_hashjoin true > > Nouns sound stranger and more awkward: > > geqo true > parser_stats true > hashjoin true Interesting analysis. No verb in there. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I thought about that, but is seems all our booleans could logically fall > into the category of being enabled/disabled. For add_missing_from, the > add word is so people realize that it is really _adding_ to the FROM > list, so I see it as different. > > Anyway, change committed. I can always change it back if people change > their mind. I suggest that the rule you've been (unconsciously) following is the following: parameters that form a verb phrase do not need an enable_ prefix. But parameters that form a noun phrase do or else they sound strange. Put another way, "all boolean parameters are verb phrases; if they're not then turn them into a verb phrase by prepending a verb like `enable'" I see a couple exceptions (debug_assertions, geqo) but mostly they seem to follow this pattern. I'm not sure that's a bad rule. Verbs sound nice when you read them: show_parser_stats true enable_hashjoin true Nouns sound stranger and more awkward: geqo true parser_stats true hashjoin true -- greg