I just released new version of Pg::Explain Perl library that is handling parsing of plans for explain.depesz.com.
There are quite a lot of changes, but mostly internal, but one thing is pretty interesting – Pg::Explain, and because of this also explain.depesz.com should be able to parse plans with arbitrary values of border, linestyle, format, unicode_border_linestyle, unicode_column_linestyle, and unicode_header_linestyle psql options.
You can see five simple examples already uploaded:
Continue reading Changes on explain.depesz.com
On 2nd of April 2020, Fujii Masao committed patch:
Allow pg_stat_statements to track planning statistics.
This commit makes pg_stat_statements support new GUC
pg_stat_statements.track_planning. If this option is enabled,
pg_stat_statements tracks the planning statistics of the statements,
e.g., the number of times the statement was planned, the total time
spent planning the statement, etc. This feature is useful to check
the statements that it takes a long time to plan. Previously since
pg_stat_statements tracked only the execution statistics, we could
not use that for the purpose.
The planning and execution statistics are stored at the end of
each phase separately. So there are not always one-to-one relationship
between them. For example, if the statement is successfully planned
but fails in the execution phase, only its planning statistics are stored.
This may cause the users to be able to see different pg_stat_statements
results from the previous version. To avoid this,
pg_stat_statements.track_planning needs to be disabled.
This commit bumps the version of pg_stat_statements to 1.8
since it changes the definition of pg_stat_statements function.
Author: Julien Rouhaud, Pascal Legrand, Thomas Munro, Fujii Masao
Reviewed-by: Sergei Kornilov, Tomas Vondra, Yoshikazu Imai, Haribabu Kommi, Tom Lane
Continue reading Waiting for PostgreSQL 13 – Allow pg_stat_statements to track planning statistics.
On 18th of March 2020, Alvaro Herrera committed patch:
Enable BEFORE row-level triggers for partitioned tables
... with the limitation that the tuple must remain in the same
Reviewed-by: Ashutosh Bapat
Continue reading Waiting for PostgreSQL 13 – Enable BEFORE row-level triggers for partitioned tables
Ever since I released explain.depesz.com over 11 years ago there have been cases were people would upload a plan and it didn't parse.
There were many reasons, but the most common was – plan was line-wrapped by injecting new-line characters where there shouldn't be one.
Continue reading Initial support for fixing of line-wrapped plans
Recently, on irc, there were couple of cases where someone wanted to use uuid as datatype for their primary key.
I opposed, and tried to explain, but IRC doesn't really allow for longer texts, so figured I'll write a blogpost.
Continue reading Why I'm not fan of uuid datatype
Couple of days ago RhodiumToad reported, on irc, a bug in explain.depesz.com.
Specifically – if explain was done using JSON/XML/YAML formats, and node type was Aggregate, the site didn't extract full info.
Continue reading Fix for displaying aggregates on explain.depesz.com
Some time ago I wrote blogpost which showed how to list tables that should be autovacuumed or autoanalyzed.
Query in there had one important problem – it didn't take into account per-table settings.
Continue reading Which tables should be auto vacuumed or auto analyzed – UPDATE
On 12nd of February 2020, Michael Paquier committed patch:
Add %x to default PROMPT1 and PROMPT2 in psql
%d can be used to track if the current connection is in a transaction
block or not, and adding it by default to the prompt has the advantage
to not need a modification of .psqlrc, something not possible depending
on the environment.
This discussion has happened across various sources, and there was a
strong consensus in favor of this change.
Author: Vik Fearing
Reviewed-by: Fabien Coelho
Continue reading Waiting for PostgreSQL 13 – Add %x to default PROMPT1 and PROMPT2 in psql
On 6th of February 2020, Michael Paquier committed patch:
Add leader_pid to pg_stat_activity
This new field tracks the PID of the group leader used with parallel
query. For parallel workers and the leader, the value is set to the
PID of the group leader. So, for the group leader, the value is the
same as its own PID. Note that this reflects what PGPROC stores in
shared memory, so as leader_pid is NULL if a backend has never been
involved in parallel query. If the backend is using parallel query or
has used it at least once, the value is set until the backend exits.
Author: Julien Rouhaud
Reviewed-by: Sergei Kornilov, Guillaume Lelarge, Michael Paquier, Tomas
Continue reading Waiting for PostgreSQL 13 – Add leader_pid to pg_stat_activity
Recently I was in a situation where autovacuum couldn't keep up with changes. To solve the problem I finally decided to manually vacuum analyze all tables (manual vacuum/analyze is faster than one ran by autovacuum daemon).
But it irritated me that I didn't have ready way to check which tables are waiting for autovacuum to work on them.
So, I wrote it.
Continue reading Which tables should be auto vacuumed or auto analyzed?