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
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
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
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
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
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
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
"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
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
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';
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
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:
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
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
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
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
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
17 matches
Mail list logo