Jim Nasby <[EMAIL PROTECTED]> writes:
> On Mar 25, 2007, at 12:31 PM, Tom Lane wrote:
>> The other argument was that you might not want the costs of searching
>> for contradictory constraints if your workload was such that the
>> search
>> never or hardly ever succeeds. That still justifies the
On Mar 25, 2007, at 12:31 PM, Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
On Mar 21, 2007, at 5:11 AM, Tom Lane wrote:
constraint_exclusion
Hrm... wasn't that option added in case there was a bug in the
exclusion code?
Well, the "bug" was a lack of ways to get rid of plans that w
Jim Nasby <[EMAIL PROTECTED]> writes:
> On Mar 21, 2007, at 5:11 AM, Tom Lane wrote:
>> constraint_exclusion
> Hrm... wasn't that option added in case there was a bug in the
> exclusion code?
Well, the "bug" was a lack of ways to get rid of plans that were
no longer valid because of constraint
"Jim Nasby" <[EMAIL PROTECTED]> writes:
> On Mar 21, 2007, at 5:11 AM, Tom Lane wrote:
>> constraint_exclusion
>>
>> I'm inclined not to worry about these, since changing them can't affect
>> the semantics of the query, at worst its performance.
>
> Hrm... wasn't that option added in case the
On Mar 21, 2007, at 5:11 AM, Tom Lane wrote:
constraint_exclusion
I'm inclined not to worry about these, since changing them can't
affect
the semantics of the query, at worst its performance.
Hrm... wasn't that option added in case there was a bug in the
exclusion code? I certainl
On 3/21/2007 1:46 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 3/20/2007 1:11 PM, Tom Lane wrote:
search_path
add_missing_from
transform_null_equals
sql_inheritance
Don't we actually store the parsetree in the query cache, and doesn't
that actually make a lot of the above rat
Jan Wieck <[EMAIL PROTECTED]> writes:
> On 3/20/2007 1:11 PM, Tom Lane wrote:
>> search_path
>> add_missing_from
>> transform_null_equals
>> sql_inheritance
> Don't we actually store the parsetree in the query cache, and doesn't
> that actually make a lot of the above rather NOT affect the result
On 3/20/2007 1:11 PM, Tom Lane wrote:
Now that there's a mechanism in the backend that will automatically replan
queries whenever anything changes about the referenced tables, we have to
worry about whether an automatic replan might cause surprising changes in
the behavior of a query. I looked t
Josh Berkus writes:
> Tom Lane wrote:
>> sql_inheritance is a little bit
>> bigger deal, but I wonder whether we shouldn't just remove that variable
>> altogether --- it's been default ON since 7.1 and I've not heard anyone
>> complain about that in a long time.
> Let's do a quick survey on a cou
Tom Lane wrote:
Now that there's a mechanism in the backend that will automatically replan
queries whenever anything changes about the referenced tables, we have to
worry about whether an automatic replan might cause surprising changes in
the behavior of a query. I looked through the available G
Now that there's a mechanism in the backend that will automatically replan
queries whenever anything changes about the referenced tables, we have to
worry about whether an automatic replan might cause surprising changes in
the behavior of a query. I looked through the available GUC settings to
see
11 matches
Mail list logo
