On Sun, Feb 5, 2012 at 12:44 AM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> Yeah, I think we need to preserve that property. Unexpectedly
>> executing query (which may have side-effects) is a very dangerous
>> thing. People are used to the idea that ANALYZE == execute, and
>> adding random oth
Tom Lane wrote:
> Yeah, I think we need to preserve that property. Unexpectedly
> executing query (which may have side-effects) is a very dangerous
> thing. People are used to the idea that ANALYZE == execute, and
> adding random other flags that also cause execution is going to
> burn somebody
Jeff Janes writes:
> I suspect we will be unwilling to make such a break with the past. In
> that case, I think I prefer the originally proposed semantics, even
> though I agree they are somewhat less natural. ANALYZE is a big flag
> that means "This query will be executed, not just planned". I
On Fri, Feb 3, 2012 at 8:12 AM, Robert Haas wrote:
> On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes wrote:
>> On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra wrote:
>>>
>>> Fixed. The default value of TIMING option did not work as intended, it
>>> was set to true even for plain EXPLAIN (without ANAL
On 3.2.2012 22:51, Robert Haas wrote:
> On Fri, Feb 3, 2012 at 2:56 PM, Tomas Vondra wrote:
>> OK, thanks for the explanation. I don't like the idea of subsets as it
>> IMHO makes it less obvious what options are enabled. For example this
>>
>> EXPLAIN (ROWS) query...
>>
>> does not immediately
On Fri, Feb 3, 2012 at 2:56 PM, Tomas Vondra wrote:
> OK, thanks for the explanation. I don't like the idea of subsets as it
> IMHO makes it less obvious what options are enabled. For example this
>
> EXPLAIN (ROWS) query...
>
> does not immediately show it's actually going to do ANALYZE.
Well,
On 3.2.2012 18:28, Robert Haas wrote:
> On Fri, Feb 3, 2012 at 12:08 PM, Tomas Vondra wrote:
>> I don't think changing the EXPLAIN syntax this way is a good idea. I think
>> that one option should not silently enable/disable others, so ROWS should
>> not enable ANALYZE automatically.
>
> I didn't
On Fri, Feb 3, 2012 at 12:08 PM, Tomas Vondra wrote:
> I don't think changing the EXPLAIN syntax this way is a good idea. I think
> that one option should not silently enable/disable others, so ROWS should
> not enable ANALYZE automatically.
I didn't propose that. The point is that the desired b
On 3 Únor 2012, 17:12, Robert Haas wrote:
> On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes wrote:
>> On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra wrote:
>>>
>>> Fixed. The default value of TIMING option did not work as intended, it
>>> was set to true even for plain EXPLAIN (without ANALYZE). In t
On Sat, Jan 21, 2012 at 10:32 PM, Jeff Janes wrote:
> On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra wrote:
>>
>> Fixed. The default value of TIMING option did not work as intended, it
>> was set to true even for plain EXPLAIN (without ANALYZE). In that case
>> the EXPLAIN failed.
>>
>
> I've appl
On Fri, Jan 13, 2012 at 3:07 PM, Tomas Vondra wrote:
>
> Fixed. The default value of TIMING option did not work as intended, it
> was set to true even for plain EXPLAIN (without ANALYZE). In that case
> the EXPLAIN failed.
>
I've applied this over the "show Heap Fetches in EXPLAIN ANALYZE
output
On 13.1.2012 18:07, Josh Berkus wrote:
> Eric's review follows:
>
> Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from
> 2012-01-12 git checkout.
>
> Patch applied fine.
>
> 'make check' results in failures when this patch is put into place.
>
>
> 6 o
Eric's review follows:
Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from
2012-01-12 git checkout.
Patch applied fine.
'make check' results in failures when this patch is put into place.
6 of 128 tests failed.
Here are the re
13 matches
Mail list logo
