On Thu, Sep 22, 2011 at 02:41:12AM -0400, Tom Lane wrote:
> Yeah, I thought seriously about that too. The problem with it is that
> you end up having to print that line all the time, whether or not it
> adds any knowledge. The "filter removed N rows" approach has the saving
> grace that you can l
Heikki Linnakangas writes:
> I haven't been following this closely, so sorry if this has already been
> discussed, but:
> I find it a bit strange to print the number of lines filtered out. I
> think that's the only place where we would print a "negative" like that,
> everywhere else we print t
On 22.09.2011 07:51, Tom Lane wrote:
Here's a revised version of the patch that behaves in a way that seems
reasonable to me, in particular it suppresses zero filter-count rows in
text mode. I've not done anything yet about the documentation.
I haven't been following this closely, so sorry if
Here's a revised version of the patch that behaves in a way that seems
reasonable to me, in particular it suppresses zero filter-count rows in
text mode. I've not done anything yet about the documentation.
regards, tom lane
diff --git a/src/backend/commands/explain.c b/sr
Robert Haas writes:
> On Tue, Sep 20, 2011 at 8:19 PM, Tom Lane wrote:
>> I find it useless and probably confusing to put out "Rows Removed
>> by Recheck Cond: 0" unless we're dealing with a lossy index.
> I don't really see the point of this. I think printing it always is
> both clear and appr
On Tue, Sep 20, 2011 at 8:19 PM, Tom Lane wrote:
> Marko Tiikkaja writes:
>>> The attached patch is the best I could come up with. I considered
>>> showing "Rows Removed by Foo: (never executed)" and omitting the line
>>> altogether, but I didn't particularly like either of those options. The
>
Marko Tiikkaja writes:
>> The attached patch is the best I could come up with. I considered
>> showing "Rows Removed by Foo: (never executed)" and omitting the line
>> altogether, but I didn't particularly like either of those options. The
>> current patch simply displays "Rows Removed by Foo
Marko Tiikkaja writes:
> The attached patch is the best I could come up with. I considered
> showing "Rows Removed by Foo: (never executed)" and omitting the line
> altogether, but I didn't particularly like either of those options. The
> current patch simply displays "Rows Removed by Foo: 0"
On 12/09/2011 12:12, I wrote:
On 2011-09-10 19:50, Marti Raudsepp wrote:
I tried this patch and noticed something weird. This is probably not
intentional:
Indeed, it is not intentional. Will see how I can fix this.
The attached patch is the best I could come up with. I considered
showing
Hi,
On 2011-09-10 19:50, Marti Raudsepp wrote:
I tried this patch and noticed something weird. This is probably not
intentional:
Indeed, it is not intentional. Will see how I can fix this.
Thank you for trying the patch out!
--
Marko Tiikkajahttp://www.2ndQuadrant.com/
Post
Hi!
On Thu, Sep 8, 2011 at 15:11, Marko Tiikkaja
wrote:
> Here's a patch for $SUBJECT based on the feedback here:
> http://archives.postgresql.org/message-id/9053.1295888...@sss.pgh.pa.us
I tried this patch and noticed something weird. This is probably not
intentional:
explain analyze select *
Hi,
Here's a patch for $SUBJECT based on the feedback here:
http://archives.postgresql.org/message-id/9053.1295888...@sss.pgh.pa.us
I intentionally decided to omit the information for Join Filter, since
the information can already be deduced from EXPLAIN ANALYZE output, and
for Left Joins and
On 2010-11-18 5:45 PM +0200, Marko Tiikkaja wrote:
Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
qual filtered from a node's input.
Rebased against master.
Regards,
Marko Tiikkaja
*** a/src/backend/commands/explain.c
--- b/src/backend/commands/explain.c
*
On Thu, Nov 18, 2010 at 10:45 AM, Marko Tiikkaja
wrote:
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan qual
> filtered from a node's input. The output looks like this:
I have wished for this many, MANY times.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
T
On 2010-11-18 6:44 PM +0200, Andres Freund wrote:
On Thursday 18 November 2010 16:45:23 Marko Tiikkaja wrote:
Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
qual filtered from a node's input. The output looks like this:
If it supports the same for index-scans I *really
On Thursday 18 November 2010 17:48:43 Marko Tiikkaja wrote:
> On 2010-11-18 6:44 PM +0200, Andres Freund wrote:
> > On Thursday 18 November 2010 16:45:23 Marko Tiikkaja wrote:
> >> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
> >
> >> qual filtered from a node's input.
On Thursday 18 November 2010 16:45:23 Marko Tiikkaja wrote:
> Hi,
>
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
> qual filtered from a node's input. The output looks like this:
If it supports the same for index-scans I *really* like it and even proposed a
patch earl
On 2010-11-18 6:26 PM +0200, Tom Lane wrote:
Marko Tiikkaja writes:
Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
qual filtered from a node's input.
I don't like this a whole lot. It's unclear what "filtered" means,
or why it's worth expending precious EXPLAIN ANALY
Marko Tiikkaja writes:
> Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
> qual filtered from a node's input.
I don't like this a whole lot. It's unclear what "filtered" means,
or why it's worth expending precious EXPLAIN ANALYZE output space for.
Also, you've not imple
Hi,
Here's a patch for showing in EXPLAIN ANALYZE the number of rows a plan
qual filtered from a node's input. The output looks like this:
QUERY PLAN
-
20 matches
Mail list logo
