Re: slight tweaks to documentation about runtime pruning

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: slight tweaks to documentation about runtime pruning
Дата
Msg-id CAKJS1f9tD+sEHAgX=45PndbXVXQ0g6OJStHMdr9mHrqjX3C1wg@mail.gmail.com
обсуждение исходный текст
Ответ на slight tweaks to documentation about runtime pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: slight tweaks to documentation about runtime pruning  (Amit Langote <amitlangote09@gmail.com>)
Re: slight tweaks to documentation about runtime pruning  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Wed, 5 Dec 2018 at 20:24, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Documentation of run-time pruning tells readers to inspect "nloops"
> property of the EXPLAIN ANALYZE output, but I think that's a typo of
> "loops" which is actually output ("internal variable to track that
> property is indeed nloops).

I agree. The 'n' should be dropped there.

> However, for pruned partitions' subplans, what's actually shown is the
> string "(never executed)", not loops.  So, wouldn't it be better to tell
> the readers to look for that instead of "loops"?

I don't really see any issues with the existing documentation here.
Remember that pruning can be performed multiple times when a parameter
changes that was found to match the partition key and the
Append/MergeAppend is rescanned. For example:

create table listp (a int) partition by list(a);
create table listp1 partition of listp for values in(1);
create table listp2 partition of listp for values in(2);
create index on listp(a);
set enable_bitmapscan=0;
explain analyze select * from (values(1),(1),(2)) a(a) inner join
listp l on a.a = l.a;
                                                                 QUERY PLAN

--------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.15..91.50 rows=76 width=8) (actual
time=0.013..0.013 rows=0 loops=1)
   ->  Values Scan on "*VALUES*"  (cost=0.00..0.04 rows=3 width=4)
(actual time=0.001..0.002 rows=3 loops=1)
   ->  Append  (cost=0.15..30.23 rows=26 width=4) (actual
time=0.003..0.003 rows=0 loops=3)
         ->  Index Only Scan using listp1_a_idx on listp1 l
(cost=0.15..15.05 rows=13 width=4) (actual time=0.002..0.002 rows=0
loops=2)
               Index Cond: (a = "*VALUES*".column1)
               Heap Fetches: 0
         ->  Index Only Scan using listp2_a_idx on listp2 l_1
(cost=0.15..15.05 rows=13 width=4) (actual time=0.003..0.003 rows=0
loops=1)
               Index Cond: (a = "*VALUES*".column1)
               Heap Fetches: 0
 Planning Time: 0.158 ms
 Execution Time: 0.042 ms
(11 rows)

listp1 was scanned twice (loops=2), listp2 was scanned just once.

Now it is true that if the subplan was executed 0 times that it will
appear as "(never executed)", but do we really need to explain in this
area that "(never executed)" means loops=0?

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [Todo item] Add entry creation timestamp column topg_stat_replication
Следующее
От: David Rowley
Дата:
Сообщение: Re: Should new partitions inherit their tablespace from their parent?