Re: Display of buffers for planning time show nothing for second run - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Display of buffers for planning time show nothing for second run
Date
Msg-id CAOBaU_YLnymCp_exJ3hnmcDui+LAEVYQYwmYby4tW7W2CeBZkw@mail.gmail.com
Whole thread Raw
In response to Re: Display of buffers for planning time show nothing for second run  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Display of buffers for planning time show nothing for second run  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Tue, Apr 14, 2020 at 10:36 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> út 14. 4. 2020 v 10:27 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
>>
>> Hi,
>>
>> On Tue, Apr 14, 2020 at 10:18 AM Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> >
>> > Hi
>> >
>> > I am testing some features from Postgres 13, and I am not sure if I  understand well to behave of EXPLAIN(ANALYZE,
BUFFERS)
>> >
>> > When I run following statement first time in session I get
>> >
>> > postgres=# EXPLAIN (BUFFERS, ANALYZE) SELECT * FROM obce WHERE okres_id = 'CZ0201';
>> >
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
>> > │                                                          QUERY PLAN
           │
 
>> >
╞══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
>> > │ Index Scan using obce_okres_id_idx on obce  (cost=0.28..14.49 rows=114 width=41) (actual time=0.072..0.168
rows=114loops=1) │
 
>> > │   Index Cond: ((okres_id)::text = 'CZ0201'::text)
           │
 
>> > │   Buffers: shared hit=4
           │
 
>> > │ Planning Time: 0.539 ms
           │
 
>> > │   Buffers: shared hit=13
           │
 
>> > │ Execution Time: 0.287 ms
           │
 
>> >
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
>> > (6 rows)
>> >
>> > And I see share hit 13 in planning time.
>> >
>> > For second run I get
>> >
>> > postgres=# EXPLAIN (BUFFERS, ANALYZE) SELECT * FROM obce WHERE okres_id = 'CZ0201';
>> >
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
>> > │                                                          QUERY PLAN
           │
 
>> >
╞══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
>> > │ Index Scan using obce_okres_id_idx on obce  (cost=0.28..14.49 rows=114 width=41) (actual time=0.044..0.101
rows=114loops=1) │
 
>> > │   Index Cond: ((okres_id)::text = 'CZ0201'::text)
           │
 
>> > │   Buffers: shared hit=4
           │
 
>> > │ Planning Time: 0.159 ms
           │
 
>> > │ Execution Time: 0.155 ms
           │
 
>> >
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
>> > (5 rows)
>> >
>> > Now, there is not any touch in planning time. Does it mean so this all these data are cached somewhere in session
memory?
>>
>> The planning time is definitely shorter the 2nd time.  And yes, what
>> you see are all the catcache accesses that are initially performed on
>> a fresh new backend.
>
>
> One time Tom Lane mentioned using index in planning time for getting minimum and maximum. I expected so these values
arenot cached. But I cannot to reproduce it, and then I am little bit surprised so I don't see any hit in second, and
otherexecutions.
 

Isn't that get_actual_variable_range() purpose?  If you use a plan
that hit this function you'll definitely see consistent buffer usage
during planning:

rjuju=# explain (buffers, analyze) select * from pg_class c join
pg_attribute a on a.attrelid = c.oid;
                                                      QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------
 Hash Join  (cost=21.68..110.91 rows=2863 width=504) (actual
time=0.393..5.989 rows=2863 loops=1)
   Hash Cond: (a.attrelid = c.oid)
   Buffers: shared hit=40 read=29
   ->  Seq Scan on pg_attribute a  (cost=0.00..81.63 rows=2863
width=239) (actual time=0.010..0.773 rows=2863 loops=1)
         Buffers: shared hit=28 read=25
   ->  Hash  (cost=16.86..16.86 rows=386 width=265) (actual
time=0.333..0.334 rows=386 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 85kB
         Buffers: shared hit=9 read=4
         ->  Seq Scan on pg_class c  (cost=0.00..16.86 rows=386
width=265) (actual time=0.004..0.123 rows=386 loops=1)
               Buffers: shared hit=9 read=4
 Planning Time: 2.709 ms
   Buffers: shared hit=225 read=33
 Execution Time: 6.529 ms
(13 rows)

rjuju=# explain (buffers, analyze) select * from pg_class c join
pg_attribute a on a.attrelid = c.oid;
                                                      QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------
 Hash Join  (cost=21.68..110.91 rows=2863 width=504) (actual
time=0.385..5.613 rows=2863 loops=1)
   Hash Cond: (a.attrelid = c.oid)
   Buffers: shared hit=66
   ->  Seq Scan on pg_attribute a  (cost=0.00..81.63 rows=2863
width=239) (actual time=0.012..0.541 rows=2863 loops=1)
         Buffers: shared hit=53
   ->  Hash  (cost=16.86..16.86 rows=386 width=265) (actual
time=0.352..0.352 rows=386 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 85kB
         Buffers: shared hit=13
         ->  Seq Scan on pg_class c  (cost=0.00..16.86 rows=386
width=265) (actual time=0.003..0.092 rows=386 loops=1)
               Buffers: shared hit=13
 Planning Time: 0.575 ms
   Buffers: shared hit=12
 Execution Time: 5.985 ms
(13 rows)

rjuju=# explain (buffers, analyze) select * from pg_class c join
pg_attribute a on a.attrelid = c.oid;
                                                      QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------
 Hash Join  (cost=21.68..110.91 rows=2863 width=504) (actual
time=0.287..5.612 rows=2863 loops=1)
   Hash Cond: (a.attrelid = c.oid)
   Buffers: shared hit=66
   ->  Seq Scan on pg_attribute a  (cost=0.00..81.63 rows=2863
width=239) (actual time=0.008..0.553 rows=2863 loops=1)
         Buffers: shared hit=53
   ->  Hash  (cost=16.86..16.86 rows=386 width=265) (actual
time=0.261..0.262 rows=386 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 85kB
         Buffers: shared hit=13
         ->  Seq Scan on pg_class c  (cost=0.00..16.86 rows=386
width=265) (actual time=0.003..0.075 rows=386 loops=1)
               Buffers: shared hit=13
 Planning Time: 0.483 ms
   Buffers: shared hit=12
 Execution Time: 5.971 ms
(13 rows)

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Display of buffers for planning time show nothing for second run
Next
From: Julien Rouhaud
Date:
Subject: Re: Display of buffers for planning time show nothing for second run