Waiting for 9.6 – Add a \gexec command to psql for evaluation of computed queries.

On 4th of April, Tom Lane committed patch:

Add a \gexec command to psql for evaluation of computed queries.
 
\gexec executes the just-entered query, like \g, but instead of printing
the results it takes each field as a SQL command to send to the server.
Computing a series of queries to be executed is a fairly common thing,
but up to now you always had to resort to kluges like writing the queries
to a file and then inputting the file.  Now it can be done with no
intermediate step.
 
The implementation is fairly straightforward except for its interaction
with FETCH_COUNT.  ExecQueryUsingCursor isn't capable of being called
recursively, and even if it were, its need to create a transaction
block interferes unpleasantly with the desired behavior of \gexec after
a failure of a generated query (i.e., that it can continue).  Therefore,
disable use of ExecQueryUsingCursor when doing the master \gexec query.
We can still apply it to individual generated queries, however, and there
might be some value in doing so.
 
While testing this feature's interaction with single-step mode, I (tgl) was
led to conclude that SendQuery needs to recognize SIGINT (cancel_pressed)
as a negative response to the single-step prompt.  Perhaps that's a
back-patchable bug fix, but for now I just included it here.
 
Corey Huinker, reviewed by Jim Nasby, Daniel Vérité, and myself

Continue reading Waiting for 9.6 – Add a \gexec command to psql for evaluation of computed queries.

Waiting for 9.6 – Bloom index contrib module

On 1st of April, Teodor Sigaev committed patch:

Bloom index contrib module
 
Module provides new access method. It is actually a simple Bloom filter
implemented as pgsql's index. It could give some benefits on search
with large number of columns.
 
Module is a single way to test generic WAL interface committed earlier.
 
Author: Teodor Sigaev, Alexander Korotkov
Reviewers: Aleksander Alekseev, Michael Paquier, Jim Nasby

Continue reading Waiting for 9.6 – Bloom index contrib module

Change on explain.depesz.com

As of now, main table that stores explain.depesz.com plans is partitioned.

This shouldn't be, at all, visible for users of the site, but if it would, please let me know (on irc, or via email).

In case you're wondering why, after all there is only ~ 270,000 plans – the reason is very simple. Splitting the data into multiple tables makes maintenance tasks (vacuum, dump) much simpler and easier.

Waiting for 9.6 – Support parallel aggregation.

On 21st of March, Robert Haas committed patch:

Support parallel aggregation.
 
Parallel workers can now partially aggregate the data and pass the
transition values back to the leader, which can combine the partial
results to produce the final answer.
 
David Rowley, based on earlier work by Haribabu Kommi.  Reviewed by
Álvaro Herrera, Tomas Vondra, Amit Kapila, James Sewell, and me.

Continue reading Waiting for 9.6 – Support parallel aggregation.

Waiting for 9.6 – Directly modify foreign tables.

On 18th of March, Robert Haas committed patch:

Directly modify foreign tables.
 
postgres_fdw can now sent an UPDATE or DELETE statement directly to
the foreign server in simple cases, rather than sending a SELECT FOR
UPDATE statement and then updating or deleting rows one-by-one.
 
Etsuro Fujita, reviewed by Rushabh Lathia, Shigeru Hanada, Kyotaro
Horiguchi, Albe Laurenz, Thom Brown, and me.

Continue reading Waiting for 9.6 – Directly modify foreign tables.

Waiting for 9.6 – Add idle_in_transaction_session_timeout.

On 16th of March, Robert Haas committed patch:

Add idle_in_transaction_session_timeout.
 
Vik Fearing, reviewed by Stéphane Schildknecht and me, and revised
slightly by me.

Continue reading Waiting for 9.6 – Add idle_in_transaction_session_timeout.

Waiting for 9.6 – Add simple VACUUM progress reporting.

On 15th of March, Robert Haas committed patch:

Add simple VACUUM progress reporting. 
 
There's a lot more that could be done here yet - in particular, this
reports only very coarse-grained information about the index vacuuming
phase - but even as it stands, the new pg_stat_progress_vacuum can
tell you quite a bit about what a long-running vacuum is actually
doing.
 
Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale
and Rahila Syed.

Continue reading Waiting for 9.6 – Add simple VACUUM progress reporting.

Waiting for 9.6 – Tsvector editing functions

On 11th of March, Teodor Sigaev committed patch:

Tsvector editing functions
 
Adds several tsvector editting function: convert tsvector to/from text array,
set weight for given lexemes, delete lexeme(s), unnest, filter lexemes
with given weights
 
Author: Stas Kelvich with some editorization by me
Reviewers: Tomas Vondram, Teodor Sigaev

Continue reading Waiting for 9.6 – Tsvector editing functions

Waiting for 9.6 – Add a generic command progress reporting facility.

On 9th of March, Robert Haas committed patch:

Add a generic command progress reporting facility.
 
Using this facility, any utility command can report the target relation
upon which it is operating, if there is one, and up to 10 64-bit
counters; the intent of this is that users should be able to figure out
what a utility command is doing without having to resort to ugly hacks
like attaching strace to a backend.
 
As a demonstration, this adds very crude reporting to lazy vacuum; we
just report the target relation and nothing else.  A forthcoming patch
will make VACUUM report a bunch of additional data that will make this
much more interesting.  But this gets the basic framework in place.
 
Vinayak Pokale, Rahila Syed, Amit Langote, Robert Haas, reviewed by
Kyotaro Horiguchi, Jim Nasby, Thom Brown, Masahiko Sawada, Fujii Masao,
and Masanori Oyama.

Continue reading Waiting for 9.6 – Add a generic command progress reporting facility.

Waiting for 9.6 – Add new system view, pg_config

On 17th of February, Joe Conway committed patch:

Add new system view, pg_config
 
Move and refactor the underlying code for the pg_config client
application to src/common in support of sharing it with a new
system information SRF called pg_config() which makes the same
information available via SQL. Additionally wrap the SRF with a
new system view, as called pg_config.
 
Patch by me with extensive input and review by Michael Paquier
and additional review by Alvaro Herrera.

Continue reading Waiting for 9.6 – Add new system view, pg_config