Re: EXPLAIN and nfiltered, take two

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

In response to

Responses

Browse pgsql-hackers by date

  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