ing?
My understanding from the documentation is that it does not need autoanalyze
stats.
Thanks
Thank you
From: Justin Pryzby
Sent: Wednesday, February 27, 2019 11:15 AM
To: Fd Habash
Cc: pgsql-performa...@postgresql.org
Subject: Re: What is pg_stat_user_tables Showing NULL for last_aut
I have been able to locate four google search results with the same inquiry.
What’ve been able to understand is …
1. If auto-vaccum is working as expected, stats collector does not nullify
these values as part of a startup sequence or regular Maitenance. If a relation
gets auto[vacuumed|analyze
In API function may invoke 10 queries. Ideally, I would like to know what
queries are invoked by it and how long each took.
I’m using pg_stat_statement. I can see the API function statement, but how do I
deterministically identify all queries invoked by it?
Thank you
Just checked metrics while the count was running …
Read latency < 3.5 ms
Write latency < 4 ms
Read throughput ~ 40 MB/sec with sporadic peaks at 100
Read IOPS ~ 5000
QDepth < 3
Thank you
From: Tom Lane
Sent: Thursday, September 13, 2018 2:12 PM
To: Fd Habash
Based on my research in the forums and Google , it is described in multiple
places that ‘select count(*)’ is expected to be slow in Postgres because of the
MVCC controls imposed upon the query leading a table scan. Also, the elapsed
time increase linearly with table size.
However, I do not kno
Jeremy …
In your statement, what constitutes ‘heavy use of exception blocks’?
Thanks
I have seen
applications grind to a halt on SubtransControlLock when they make heavy
use of exception blocks in plpgsql code; in fact it's pretty
straightforward to demonstrate this behavior with pgbench on
Thanks, Jeremy …
“ That said... FWIW, Aurora PostgreSQL version 9.6.3 uses parent/child
transaction relationships pretty much the same way that community PostgreSQL
9.6.3 does …”
This is why I posted here first. This particular wait state did not appear to
be Aurora specific and was not listed
Indexes are being redone as per these insights. Appreciate the great support.
Thank you
From: Matthew Hall
Sent: Tuesday, June 5, 2018 10:42 AM
To: Fred Habash
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Simple Query Elapsed Time ~ 3 hrs Using Bitmap Index/Heap Scan