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_YB6tg5C1uK-FYJyJB1nM46ifpt-Jb6sYSXtC89fONdRg@mail.gmail.com
Whole thread Raw
In response to 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>)
Re: Display of buffers for planning time show nothing for second run  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
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=114
loops=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=114
loops=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.

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Display of buffers for planning time show nothing for second run
Next
From: Andy Fan
Date:
Subject: Re: index paths and enable_indexscan