Magnus Hagander <mag...@hagander.net> writes:
> Also, unrelated to that, wouldn't this information be interesting for
> non-autovacuum queries as well?

I was about to say that I would like to see it for normal queries too,
but I guess we already have it:

=> explain (analyze, buffers, costs off)
   select * from pg_attribute a join pg_class c on a.attrelid = c.oid;          
                                                                                
    
                                   QUERY PLAN                                   
--------------------------------------------------------------------------------
 Hash Join (actual time=0.569..4.255 rows=2158 loops=1)
   Hash Cond: (a.attrelid = c.oid)
   Buffers: shared hit=48
   ->  Seq Scan on pg_attribute a (actual time=0.008..0.462 rows=2158 loops=1)
         Buffers: shared hit=40
   ->  Hash (actual time=0.541..0.541 rows=282 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 54kB
         Buffers: shared hit=8
         ->  Seq Scan on pg_class c (actual time=0.010..0.269 rows=282 loops=1)
               Buffers: shared hit=8
 Total runtime: 4.551 ms
(11 rows)


Also, from where I sit the ps title update for normal queries is about
useless, as I see loads of IDLE postgresql backends in top that are
consuming 20% and more CPU time.  The refresh rate is way to low to be
useful, and having the title it updated more frequently would probably
consume enough CPU that it would defeat its purpose (going from
instrumenting to slowing down enough that you can see what's happening
is not where I'd want to go).


Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to