Comments for Michael Paquier

Comment on Improvements for pg_top: new features and better user experience by Lukas

Lukas — Mon, 10 Jun 2013 16:01:36 +0000

Maybe some cluster related statistics (difference between master and slave) can be helpful. At least I am using the following quite a lot.


psql -U postgres -c "SELECT pg_current_xlog_location(),  state, sync_state, flush_location  FROM pg_stat_replication;" 
 pg_current_xlog_location |   state   | sync_state | flush_location 
--------------------------+-----------+------------+----------------
 0/A20CEA88               | streaming | async      | 0/A20CEA88

Comment on Postgres 9.3 feature highlight: Materialized views by Pietro

Pietro — Wed, 05 Jun 2013 14:07:42 +0000

ok thank you!

Comment on Postgres 9.3 feature highlight: Materialized views by Michael

Michael — Tue, 04 Jun 2013 13:24:10 +0000

9.2 was released beginning of September. You can expect a similar timeline for 9.3.

Comment on Postgres 9.3 feature highlight: Materialized views by Pietro

Pietro — Tue, 04 Jun 2013 10:27:50 +0000

Do you know when will released the public stable 9.3 version of PostgreSQL?

Comment on Postgres 9.4 devel: MVCC catalog access by Robert Treat

Robert Treat — Thu, 30 May 2013 11:58:02 +0000

Jesper, you have a valid point about some people having lots of active connections; we’ve certainly had to run some of our databases with several hundred connections even *with* pg_bouncer and similar pooler. However, I’d note the worst case scenario (30% performance loss) you need 2000 connections, and even on beefy boxes that number of concurrent connections is going to be problematic.

The thing is, while we’ve done database operations in all of the above scenarios, in just about every one of them concurrent reindex, cluster, and alter table would have made things a whole lot easier (fwiw, we were early adopters of pg_reorg/repack, and we’ve been working to add alter table into it as well) so I’m likely willing to make the performance trade-off. (especially for DDL, even in our systems where we do high levels of DDL changes, if those changes were MVCC safe, the performance of them would matter less).

Comment on Postgres 9.4 devel: MVCC catalog access by Jesper

Jesper — Thu, 30 May 2013 07:56:13 +0000

some of us really cannot gain any cut in connections using a connection pooler since we are doing updates from many clients that need open transactions while doing it. 300 open transactions are everyday here. Just to keep in mind that the connection pooler trick doesnt fit all of us

Jesper

Comment on Postgres 9.3 feature highlight: JSON operators by Jay

Jay — Mon, 27 May 2013 05:33:42 +0000

oh no, a sql function returning rows, what a horrible design.

Comment on Postgres 9.3 feature highlight: JSON parsing functions by Ilker

Ilker — Fri, 24 May 2013 10:19:56 +0000

Thanks michael!

Comment on Postgres 9.3 feature highlight: JSON parsing functions by Michael

Michael — Mon, 20 May 2013 23:01:46 +0000

You can do that by applying AS clause:
postgres=# SELECT json_data.key AS key1, json_data.value AS value1 FROM customers, json_each_text(customers.education) AS json_data WHERE value = 'NYSU'; key1 | value1 --------+-------- school | NYSU (1 row)

Comment on Postgres 9.3 feature highlight: JSON parsing functions by Ilker

Ilker — Mon, 20 May 2013 13:55:27 +0000

Hi,

I’ve just upgraded to Postgresql 9.3beta. When I apply json_each or json_each_text functions to a json column, the result is a set of rows with column names ‘key’ and ‘value’.

Is there a way to get different column names like ‘key1′ and ‘value1′ after applying those functions?