Hi All,
We lowered shared_buffers to 8G and increased effective_cache_size
accordingly. So far, we haven't seen any issues since the adjustment. The
issues have come and gone in the past, so I'm not convinced it won't crop
up again, but I think the best course is to wait a week or so and see how
Jim Nasby wrote:
> If you setup some form of replication it's very easy to move to
> larger servers as you grow. I'm sure that when Kevin moved their
> database it was a complete non-event.
Yeah, replication was turned on for the new server in addition to
the old one. When everything was ready
On 8/31/13 8:35 AM, Łukasz Walkowski wrote:
3. And this part is most interesting for me. Columns browser, eventsource,
eventtype, devicetype, operatingsystem contain a small pool of strings - for
example for devicetype this is set to Computer, Mobile, Tablet or Unknown.
Browser is set to norma
On 8/29/13 9:22 PM, Bastiaan Olij wrote:
Work well enough.. But as I'm using the same data in different reports
and I though a view might be smart. So I created a view:
create view v_costs as
select dcjobid as costjobid, sum(dcamount) as costamount
from directcosts
group by dcjobid
On 8/31/13 9:44 AM, Kevin Grittner wrote:
bsreejithin wrote:
What I posted is about a new setup that's going to come
up..Discussions are on whether to setup DB cluster to handle 1000
concurrent users.
I previously worked for Wisconsin Courts, where we had a single
server which handled about
I wrote:
--- snip ---
> So - does anybody with enough insight in the planner know if it sounds
> likely that it would choose the given plans in these two cases, or if
> it's more likely that I have a tuning problem that leads to bad
> planning?
Duh. It suddenly dawned on me that I need to look c
Hi To all Pg performance users,
we've found a strange behaviour in PostgreSQL 9.1.9.
_Here' our server not default configuration :_
default_statistics_target = 100 # pgtune wizard 2011-07-06
maintenance_work_mem = 384MB # pgtune wizard 2011-07-06
constraint_exclusion = on # pgtune wizard 2011-0
Am 11.09.2013 um 17:31 schrieb Andrew Dunstan :
> I recently had to diagnose and remedy a case such as this.
>
> The short answer is to rewrite your query so you don't have to group by so
> many things. Collect your aggregates in a common table expression query (or
> possibly more than one, dep
