2014-04-15 0:32 GMT+02:00 Mel Llaguno mllag...@coverity.com:
I was given anecdotal information regarding HFS+ performance under OSX as
being unsuitable for production PG deployments and that pg_test_fsync
could be used to measure the relative speed versus other operating systems
(such as
My 2 cents :
The results are not surprising, in the linux enviroment the i/o call of
pg_test_fsync are using O_DIRECT (PG_O_DIRECT) with also the O_SYNC or
O_DSYNC calls, so ,in practice, it is waiting the answer from the storage
bypassing the cache in sync mode, while in the Mac OS X it
On Mon, Apr 14, 2014 at 12:27 PM, Robert DiFalco
robert.difa...@gmail.comwrote:
I have several related tables that represent a call state. Let's think of
these as phone calls to simplify things. Sometimes I need to determine the
last time a user was called, the last time a user answered a
On Tue, Apr 15, 2014 at 10:56 AM, Chris Curvey ch...@chriscurvey.comwrote:
On Mon, Apr 14, 2014 at 12:27 PM, Robert DiFalco robert.difa...@gmail.com
wrote:
I have several related tables that represent a call state. Let's think of
these as phone calls to simplify things. Sometimes I need to
Actually that was exactly the initial table design. There were more fields
because for my use case there were a lot more states and certain states
have additional data (for example when a call goes from answered to
connected it also gets the user_id of the person being connected to). So
that one
I have a client wanting to test PostgreSQL on ZFS running Linux.
Other than pg_bench are there any other benchmarks that are easy to test?
One of the possible concerns is fragmentation over time. Any ideas on how
to fragment the database before running pg_bench ?
Also there is some concern
On Mon, Apr 14, 2014 at 5:19 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Mon, Apr 14, 2014 at 2:46 PM, Nick Eubank nickeub...@gmail.com wrote:
Any rules of thumb for work_mem, maintenance_work_mem, shared_buffer,
etc. for a database that DOESN'T anticipate concurrent connections and that
On Tue, Apr 15, 2014 at 9:12 AM, Nick Eubank nickeub...@gmail.com wrote:
On Mon, Apr 14, 2014 at 5:19 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I'd go with a small shared_buffers, like 128MB, and let the OS cache as
much as possible. This minimizes the amount of double buffering.
And set
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Nick Eubank
Sent: Tuesday, April 15, 2014 11:12 AM
To: Jeff Janes
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Tuning Postgres for Single connection use
On Mon, Apr 14,
Jeff Janes jeff.ja...@gmail.com writes:
On Tue, Apr 15, 2014 at 9:12 AM, Nick Eubank nickeub...@gmail.com wrote:
Quick followup Jeff: it seems that I can't set work_mem above about 1gb
(can't get to 2gb. When I update config, the values just don't change in
SHOW ALL -- integer constraint?). Is
On Tuesday, April 15, 2014, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
On Tue, Apr 15, 2014 at 9:12 AM, Nick Eubank nickeub...@gmail.com
wrote:
Quick followup Jeff: it seems that I can't set work_mem above about 1gb
(can't get to 2gb. When I update
On Tue, Apr 15, 2014 at 12:57 PM, Dave Cramer davecra...@gmail.com wrote:
I have a client wanting to test PostgreSQL on ZFS running Linux. Other
than pg_bench are there any other benchmarks that are easy to test?
Check Gregory Smith article about testing disks [1].
[1]
Hi all,
A few years ago someone said postgres windows can't set working_mem above
about 2 GB (www.postgresql.org/message-id/17895.1315869...@sss.pgh.pa.us --
seems to be same for maintenance_working_mem ). Im finding limit still
present.
I'm doing single user, single connection data intensive
13 matches
Mail list logo