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 Discussion: https://postgr.es/m/09502c40-cfe1-bb29-10f9-4b3fa7b2bbb2@2ndquadrant.com
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 Vondra Discussion: https://postgr.es/m/CAOBaU_Yy5bt0vTPZ2_LUM6cUcGeqmYNoJ8-Rgto+c2+w3defYA@mail.gmail.com
Continue reading Waiting for PostgreSQL 13 – Add leader_pid to pg_stat_activity
Some time ago I ordered some hot sauces from Heatonist – Purveyors of fine hot sauces.
Bottles arrived packaged by 3 in a small cardboard box, with some fill in material (bubble wrap I think, I might be wrong, it was ~ 6 months ago).
Some time passed, I ordered more sauces. And today the package arrived. Inside some new boxes with aesthetically pleasing design:
Inside:
There was no plastic padding, fillers or anything like this. Box has holes that keep the bottles without touching each other, and safe from (almost?) all kind of damage:
Great! I'm really happy that they managed to send those with as few plastic parts as possible (there is still small wrapper on top of each bottle, and the box itself was taped using plastic tape, not paper ones, but still – it's great to see someone doing something to reduce plastic waste.
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?
On 25th of January 2020, Dean Rasheed committed patch:
Add functions gcd() and lcm() for integer and numeric types. These compute the greatest common divisor and least common multiple of a pair of numbers using the Euclidean algorithm. Vik Fearing, reviewed by Fabien Coelho. Discussion: https://postgr.es/m/adbd3e0b-e3f1-5bbc-21db-03caf1cef0f7@2ndquadrant.com
Warsaw PostgreSQL Users Group (facebook , meetup) uploaded a song to youtube: Nothing Compares To VACUUM 🙂
On 20th of January 2020, Amit Kapila committed patch:
Allow vacuum command to process indexes in parallel. This feature allows the vacuum to leverage multiple CPUs in order to process indexes. This enables us to perform index vacuuming and index cleanup with background workers. This adds a PARALLEL option to VACUUM command where the user can specify the number of workers that can be used to perform the command which is limited by the number of indexes on a table. Specifying zero as a number of workers will disable parallelism. This option can't be used with the FULL option. Each index is processed by at most one vacuum process. Therefore parallel vacuum can be used when the table has at least two indexes. The parallel degree is either specified by the user or determined based on the number of indexes that the table has, and further limited by max_parallel_maintenance_workers. The index can participate in parallel vacuum iff it's size is greater than min_parallel_index_scan_size. Author: Masahiko Sawada and Amit Kapila Mahendra Singh and Sergei Kornilov Discussion: https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com
Continue reading Waiting for PostgreSQL 13 – Allow vacuum command to process indexes in parallel.