From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)2ndquadrant(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: EXPLAIN and nfiltered, take two |
Date: | 2011-09-22 06:41:12 |
Message-ID: | 11416.1316673672@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> 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 the number of lines let through a node. How
> about printing the number of lines that enter the filter, instead?
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 leave it out when no filtering is happening. Another
point is that if you have two filters operating at a node, printing only
the starting number of rows doesn't let you disentangle which filter did
how much.
Now having said that, I could still be talked into the other way if
someone had a design that accounted for outer/semi/anti-join behavior
more clearly than this does. I thought for a little bit that printing
the starting number of rows might offer such a solution, but on
inspection it didn't really seem to help.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2011-09-22 08:36:50 | Re: Unlogged vs. In-Memory |
Previous Message | Heikki Linnakangas | 2011-09-22 06:28:42 | Re: EXPLAIN and nfiltered, take two |