Re: REVIEW: EXPLAIN and nfiltered

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: REVIEW: EXPLAIN and nfiltered
Дата
Msg-id 17474.1295715351@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: REVIEW: EXPLAIN and nfiltered  (Hitoshi Harada <umi.tanuki@gmail.com>)
Ответы Re: REVIEW: EXPLAIN and nfiltered  (David Fetter <david@fetter.org>)
Re: REVIEW: EXPLAIN and nfiltered  (Florian Pflug <fgp@phlo.org>)
Список pgsql-hackers
Hitoshi Harada <umi.tanuki@gmail.com> writes:
> 2011/1/21 Florian Pflug <fgp@phlo.org>:
>> "Rows Skipped: nnn", maybe?

> +1. Very straightforward to me.

I didn't really care for that one, because I think it *won't* be
straightforward when there's more than one filter condition at a node.
Imagine
Bitmap Heap Scan ...    Recheck Cond: blah blah    Rows Skipped: 42    Filter Cond: blah blah blah    Rows Skipped: 77

To me, "rows skipped" sounds like a statement about the overall behavior
of the plan node, and thus the above looks contradictory.  Another point
is that even if you're okay with the above for textual output, we do not
have a choice about choosing distinct field names for the two counts for
XML/JSON output.

Reflecting on that, I'm inclined to suggest
Bitmap Heap Scan ...    Recheck Cond: blah blah    Rows Removed by Recheck: 42    Filter Cond: blah blah blah    Rows
Removedby Filter: 77
 

or even more verbosely
Bitmap Heap Scan ...    Recheck Cond: blah blah    Rows Removed by Recheck Cond: 42    Filter Cond: blah blah blah
RowsRemoved by Filter Cond: 77
 

ie repeat the label of the filtering condition exactly.  This is looking
pretty long, but from the viewpoint of vertical or horizontal space
occupied by the printout, I doubt it matters.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Move test_fsync to /contrib.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Move test_fsync to /contrib.