Disabling memory display in EXPLAIN ANALYZE

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndQuadrant(dot)com>
Subject: Disabling memory display in EXPLAIN ANALYZE
Date: 2018-04-02 20:51:09
Message-ID: 20180402205109.ivzooxvyyk4lba6z@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

The, now reverted, MERGE patch used EXPLAIN (ANALYZE, COSTS OFF, TIMING
OFF) on a few queries. That doesn't seem like a bad idea when it's
interesting to display the plan and run a query without (interesting)
results. Otherwise one has to duplicate the query.

But right now it triggers differences like:

***************
*** 887,893 ****
Hash Cond: (s.sid = t_1.tid)
-> Seq Scan on source s (actual rows=3 loops=1)
-> Hash (actual rows=3 loops=1)
! Buckets: 1024 Batches: 1 Memory Usage: 9kB
-> Seq Scan on target t_1 (actual rows=3 loops=1)
Trigger merge_ard: calls=1
Trigger merge_ari: calls=1
--- 887,893 ----
Hash Cond: (s.sid = t_1.tid)
-> Seq Scan on source s (actual rows=3 loops=1)
-> Hash (actual rows=3 loops=1)
! Buckets: 1024 Batches: 1 Memory Usage: 5kB
-> Seq Scan on target t_1 (actual rows=3 loops=1)
Trigger merge_ard: calls=1
Trigger merge_ari: calls=1

***************
*** 1320,1330 ****
Merge Cond: (t_1.a = s.a)
-> Sort (actual rows=50 loops=1)
Sort Key: t_1.a
! Sort Method: quicksort Memory: 27kB
-> Seq Scan on ex_mtarget t_1 (actual rows=50 loops=1)
-> Sort (actual rows=100 loops=1)
Sort Key: s.a
! Sort Method: quicksort Memory: 33kB
-> Seq Scan on ex_msource s (actual rows=100 loops=1)
(15 rows)

--- 1320,1330 ----
Merge Cond: (t_1.a = s.a)
-> Sort (actual rows=50 loops=1)
Sort Key: t_1.a
! Sort Method: quicksort Memory: 19kB
-> Seq Scan on ex_mtarget t_1 (actual rows=50 loops=1)
-> Sort (actual rows=100 loops=1)
Sort Key: s.a
! Sort Method: quicksort Memory: 24kB
-> Seq Scan on ex_msource s (actual rows=100 loops=1)
(15 rows)

i.e. memory consumption differs between environments. Which isn't
surprising.

I wonder if we could disable the display with a separate switch or tie
it to !'COSTS OFF && TIMING OFF' or such?

Greetings,

Andres Freund

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-04-02 20:52:59 Re: BRIN FSM vacuuming questions
Previous Message Anthony Iliopoulos 2018-04-02 20:38:06 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS