On Mon, Jan 11, 2016 at 1:39 PM, Jim Nasby wrote:
> On 1/11/16 1:32 PM, Skarsol wrote:
>
>> pgbouncer (S-0x17fd780 entries):
>> 2016-01-11 12:21:46.600 32905 LOG S-0x17fd780:
>> edi01/editor@127.0.0.1:6432 <http://editor@127.0.0.1:6432> closing
>> because: s
On Fri, Nov 13, 2015 at 3:50 PM, Jim Nasby wrote:
> On 11/11/15 11:57 AM, Skarsol wrote:
>
>> Are we doing anything weird with this procedure? Is there anything more
>> I can do to get more info as to why/how the cancellation is happening or
>> why the function would slow
We're using postgres 9.2.5. Every couple of days we'll have a query get
cancelled and it is always at the start of one of our custom procedures.
The query is typically part of a php loop that runs in less than a second,
however when the issue occurs, that pass through the loop takes multiple
second
On Thu, Dec 5, 2013 at 1:19 PM, bricklen wrote:
>
> On Thu, Dec 5, 2013 at 10:08 AM, Scott Marlowe wrote:
>
>> Rules have a lot of overhead. Is there a reason you're not using
>> defaults or triggers?
>>
>
> Or for even less overhead, load the partitions directly, and preferably
> use "DEFAULT ne
On Thu, Dec 5, 2013 at 9:50 AM, Scott Marlowe wrote:
> On Thu, Dec 5, 2013 at 8:16 AM, Skarsol wrote:
> > psql (PostgreSQL) 9.2.5
> > Red Hat Enterprise Linux Server release 6.4 (Santiago)
> > Linux 2.6.32-358.6.1.el6.x86_64 #1 SMP Fri Mar 29 16:51:51 EDT 2013
> x86_
the
> filesystem used ?
>
> Thank you
>
>
> 2013/12/5 Skarsol
>
>> I'm trying to increase the speed of inserts in a database that is on a
>> not super fast storage system. I have installed a pair of SSDs and placed
>> pg_xlog on them but am still getting ins
I'm trying to increase the speed of inserts in a database that is on a not
super fast storage system. I have installed a pair of SSDs and placed
pg_xlog on them but am still getting inserts that take up to a second to
complete, with .3 seconds being about average. Iostat doesn't show the SSDs
stres
I tried sending this a couple days ago but I wasn't a member of the group
so I think it's in limbo. Apologies if a 2nd copy shows up at some point.
We recently migrated a 1.3TB database from 8.4 to 9.2.2 on a new server. As
part of this migration we added partitions to the largest tables so we
cou
