Re: slight tweaks to documentation about runtime pruning

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: slight tweaks to documentation about runtime pruning
Date: 2018-12-09 11:13:15
Message-ID: CAKJS1f9tD+sEHAgX=45PndbXVXQ0g6OJStHMdr9mHrqjX3C1wg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 5 Dec 2018 at 20:24, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-12-09 13:05:29 Re: Should new partitions inherit their tablespace from their parent?
Previous Message Michael Paquier 2018-12-09 07:44:57 Re: [Todo item] Add entry creation timestamp column to pg_stat_replication