Re: [GENERAL] Questions regarding JSON processing

On 4/25/2017 9:21 PM, Glen Huang wrote: For updating db using JSON requests from clients, that I'm not so sure. Should I directly pass the request JSON to PostgreSQL and ask it to parse this JSON and execute a transaction all by itself, or should I parse it in the server and generate the

Re: [GENERAL] Questions regarding JSON processing

2017-04-26 6:21 GMT+02:00 Glen Huang : > Hi all, > > I have a RESTful API server that sends and receives JSON strings. I'm > wondering what might be the best way to leverage PostgreSQL's JSON > capability. > > For sending JSON responses to clients. I believe the best way is to

[GENERAL] Questions regarding JSON processing

Hi all, I have a RESTful API server that sends and receives JSON strings. I'm wondering what might be the best way to leverage PostgreSQL's JSON capability. For sending JSON responses to clients. I believe the best way is to ask PostgreSQL to generate the JSON string and then pass that directly

Re: [GENERAL] pg_test_fsync performance

On 04/25/2017 05:40 AM, Karri Niemelä wrote: Hi. Wondering what sort of results are people seeing on modern servers when running pg_test_fsync? Thanks, Karri 18 sata laptop hd's (some 5400, some 7200), hardware raid 10 12 core Xeon E5645 5 seconds per test O_DIRECT supported on this

Re: [GENERAL] pg_test_fsync performance

On 04/25/2017 05:40 AM, Karri Niemelä wrote: Hi. Wondering what sort of results are people seeing on modern servers when running pg_test_fsync? Thanks, Karri 4 sata HD, hardware raid 10 4 core Xeon E5504 Box is Busy 5 seconds per test O_DIRECT supported on this platform for open_datasync

Re: [GENERAL] Questionaire: Common WAL write rates on busy servers.

Andres Freund writes: > Hi, > > I've lately seen more and more installations where the generation of > write-ahead-log (WAL) is one of the primary bottlenecks. I'm curious > whether that's primarily a "sampling error" of mine, or whether that's > indeed more common. > > The

Re: [GENERAL] Surprising results from array concatenation

On Tue, Apr 25, 2017 at 12:53 PM, Tom Lane wrote: > Yeah. The core problem here is that the parser has to disambiguate the > || operator: is it "anyarray || anyelement" or "anyarray || anyarray"? > ​<...>​ > Peeking at the contents of the literal would make the behavior

Re: [GENERAL] Surprising results from array concatenation

"David G. Johnston" writes: > On Tue, Apr 25, 2017 at 9:26 AM, Mike Blackwell > wrote: >> The docs (section 9.18 for PG 9.6) show as an example for array >> concatenation >> ARRAY[4,5,6] || 7 >> which works fine. However, trying the same with

Re: [GENERAL] Surprising results from array concatenation

On Tue, Apr 25, 2017 at 9:26 AM, Mike Blackwell wrote: > The docs (section 9.18 for PG 9.6) show as an example for array > concatenation > > ARRAY[4,5,6] || 7 > > which works fine. However, trying the same with an array of text doesn't > work: > > # select

[GENERAL] Surprising results from array concatenation

The docs (section 9.18 for PG 9.6) show as an example for array concatenation ARRAY[4,5,6] || 7 which works fine. However, trying the same with an array of text doesn't work: # select array['a','b','c'] || 'd'; ERROR: malformed array literal: "d" LINE 1: select array['a','b','c'] || 'd';

Re: [GENERAL] [PERFORM] Questionaire: Common WAL write rates on busy servers.

On Tue, Apr 25, 2017 at 1:17 AM, Andres Freund wrote: > Questions (answer as many you can comfortably answer): > - How many MB/s, segments/s do you see on busier servers? ~20MB/s with FPW compression, with peaks of ~35MB/s. Writes become the bottleneck without compression and

Re: [GENERAL] Failed dependencies for Pgadmin4 Web in Centos 7

On 04/24/2017 07:56 AM, Clodoaldo Neto wrote: On Mon, Apr 24, 2017 at 11:15 AM, Adrian Klaver > wrote: To be clear I am not a Yum/RPM expert. Where is the spec file coming from? From the pgadmin4-v1-web package:

Re: [GENERAL] pg_dump: creates dumps that cannot be restored

On Tue, Apr 25, 2017 at 4:15 AM, Thorsten Glaser wrote: > > ③ hack pg_dump to invalidate constraints before and revalidate them > after the fact. > ​I suspect there are many people who'd rather take the dump at face value then expending considerably amounts of time

Re: [GENERAL] Questionaire: Common WAL write rates on busy servers.

On Mon, Apr 24, 2017 at 9:17 PM, Andres Freund wrote: > > Questions (answer as many you can comfortably answer): > - How many MB/s, segments/s do you see on busier servers? > - What generates the bulk of WAL on your servers (9.5+ can use > pg_xlogdump --stats to compute

Re: [GENERAL] pg_dump: creates dumps that cannot be restored

Hi again, one, possibly, last, thing. I wrote: > I still find the CHECK constraint > to be a more natural way to express what I want, though. Now let me extend on this a bit. The CHECK constraint says nicely and natively, what constraints (no pun intended) I want the data to fulfil. With both

[GENERAL] pg_test_fsync performance

Hi. Wondering what sort of results are people seeing on modern servers when running pg_test_fsync? Thanks, Karri -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] [PERFORM] Questionaire: Common WAL write rates on busy servers.

Hi Andres. > 25 апр. 2017 г., в 7:17, Andres Freund написал(а): > > Hi, > > I've lately seen more and more installations where the generation of > write-ahead-log (WAL) is one of the primary bottlenecks. I'm curious > whether that's primarily a "sampling error" of mine, or