From: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: EXPLAIN and nfiltered |
Date: | 2010-11-18 16:37:01 |
Message-ID: | 4CE5562D.50009@cs.helsinki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2010-11-18 6:26 PM +0200, Tom Lane wrote:
> Marko Tiikkaja<marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> 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.
The name can be changed, of course. But I think the idea is good; I
find myself constantly manually finding out how many rows were actually
filtered.
> Also, you've not implemented it for any except scan nodes;
That was intentional.
> and I
> think it's not going to be entirely well-defined for join nodes,
> since it's somewhat arbitrary which conditions are considered part
> of the join qual versus the filter. (That problem will get worse
> not better with the planned generalization of inner indexscans,
> since there may be join quals in scan nodes.)
Hmm.. Maybe I'm misunderstanding something, but I don't see that as a
huge problem.
Regards,
Marko Tiikkaja
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-11-18 16:37:06 | Re: final patch - plpgsql: for-in-array |
Previous Message | Tom Lane | 2010-11-18 16:26:09 | Re: EXPLAIN and nfiltered |