Thread: enable_constraint_exclusion GUC name

enable_constraint_exclusion GUC name

From
Bruce Momjian
Date:
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
 


Re: enable_constraint_exclusion GUC name

From
Bruce Momjian
Date:
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
 


Re: enable_constraint_exclusion GUC name

From
Tom Lane
Date:
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


Re: enable_constraint_exclusion GUC name

From
"Joshua D. Drake"
Date:
>>
>>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/


Re: enable_constraint_exclusion GUC name

From
Bruce Momjian
Date:
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
 


Re: enable_constraint_exclusion GUC name

From
Bruce Momjian
Date:
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
 


Re: enable_constraint_exclusion GUC name

From
Greg Stark
Date:
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



Re: enable_constraint_exclusion GUC name

From
Bruce Momjian
Date:
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
 


Re: enable_constraint_exclusion GUC name

From
Greg Stark
Date:
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