On Thu, Apr 21, 2011 at 3:08 PM, Tory M Blue wrote:
> On Thu, Apr 21, 2011 at 1:04 PM, Scott Marlowe
> wrote:
>> On Thu, Apr 21, 2011 at 11:15 AM, Tory M Blue wrote:
>>
>>> While I don't mind the occasional slap of reality. This configuration
>>> has run for 4+ years. It's possible that as many
On Thu, Apr 21, 2011 at 3:08 PM, Tory M Blue wrote:
> On Thu, Apr 21, 2011 at 1:04 PM, Scott Marlowe
> wrote:
>> On Thu, Apr 21, 2011 at 11:15 AM, Tory M Blue wrote:
>>
>>> While I don't mind the occasional slap of reality. This configuration
>>> has run for 4+ years. It's possible that as many
On Thu, Apr 21, 2011 at 3:04 PM, Scott Marlowe wrote:
> Just because you've been walking around with a gun pointing at your
> head without it going off does not mean walking around with a gun
> pointing at your head is a good idea.
+1
--
Sent via pgsql-performance mailing list (pgsql-performanc
On Thu, Apr 21, 2011 at 1:04 PM, Scott Marlowe wrote:
> On Thu, Apr 21, 2011 at 11:15 AM, Tory M Blue wrote:
>
>> While I don't mind the occasional slap of reality. This configuration
>> has run for 4+ years. It's possible that as many other components each
>> fedora release is worse then the pri
On Thu, Apr 21, 2011 at 11:15 AM, Tory M Blue wrote:
> While I don't mind the occasional slap of reality. This configuration
> has run for 4+ years. It's possible that as many other components each
> fedora release is worse then the priors.
How many of those 300 max connections do you generally
Claudio,
> Am I missing something?
Yes, prepared statements.
This whole issue arises because CE is implemented purely on the planner
level. The executor can treat Immutable and Stable functions as the
same; the planner cannot, AFAIK.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
On Thu, Apr 21, 2011 at 6:15 PM, Tory M Blue wrote:
> While I don't mind the occasional slap of reality. This configuration
> has run for 4+ years. It's possible that as many other components each
> fedora release is worse then the priors.
I'd say you've been lucky.
You must be running overnight
On Thu, Apr 21, 2011 at 8:57 AM, Claudio Freire wrote:
> On Thu, Apr 21, 2011 at 5:50 PM, Tory M Blue wrote:
>> # - Checkpoints -
>> checkpoint_segments = 100
>> max_connections = 300
>> shared_buffers = 2500MB # min 128kB or max_connections*16kB
>> max_prepared_transactions = 0
>> work_mem
On Thu, Apr 21, 2011 at 5:50 PM, Tory M Blue wrote:
> # - Checkpoints -
> checkpoint_segments = 100
> max_connections = 300
> shared_buffers = 2500MB # min 128kB or max_connections*16kB
> max_prepared_transactions = 0
> work_mem = 100MB
> maintenance_work_mem = 128MB
> fsync = on
That's an
On Thu, Apr 21, 2011 at 5:53 AM, Claudio Freire wrote:
> On Thu, Apr 21, 2011 at 2:48 PM, Stephen Frost wrote:
>>
>> There's probably something else that's trying to grab all the memory and
>> then tries to use it and PG ends up getting nailed because the kernel
>> over-attributes memory to it.
On Thu, Apr 21, 2011 at 7:27 AM, Merlin Moncure wrote:
> On Thu, Apr 21, 2011 at 3:28 AM, Tory M Blue wrote:
>> Fedora 12
>> 32gig memory, 8 proc
>> postgres 8.4.4, slony 1.20
>> 5 gigs of swap (never hit it!)
>
> curious: using 32/64 bit postgres? what are your postgresql.conf
> memory settings
On Thu, Apr 21, 2011 at 3:28 AM, Tory M Blue wrote:
> Is there anyone that could help me understand why all of a sudden with
> no noticeable change in data, no change in hardware, no change in OS,
> I'm seeing postmaster getting killed by oom_killer?
>
> The dmesg shows that swap has not been touc
On Thu, Apr 21, 2011 at 2:53 PM, Claudio Freire wrote:
> On Thu, Apr 21, 2011 at 2:48 PM, Stephen Frost wrote:
>>
>> There's probably something else that's trying to grab all the memory and
>> then tries to use it and PG ends up getting nailed because the kernel
>> over-attributes memory to it.
On Thu, Apr 21, 2011 at 2:48 PM, Stephen Frost wrote:
>
> There's probably something else that's trying to grab all the memory and
> then tries to use it and PG ends up getting nailed because the kernel
> over-attributes memory to it. You should be looking for that other
> process..
Not only tha
* Tory M Blue (tmb...@gmail.com) wrote:
> Is there anyone that could help me understand why all of a sudden with
> no noticeable change in data, no change in hardware, no change in OS,
> I'm seeing postmaster getting killed by oom_killer?
You would really be best off just turning off the oom_kille
Funny concidence, I was just reading up a blog post on postgres an OOM killer.
http://gentooexperimental.org/~patrick/weblog/archives/2011-04.html#e2011-04-20T21_58_37.txt
Hope this helps.
2011/4/21 Tory M Blue :
> Is there anyone that could help me understand why all of a sudden with
> no notic
Is there anyone that could help me understand why all of a sudden with
no noticeable change in data, no change in hardware, no change in OS,
I'm seeing postmaster getting killed by oom_killer?
The dmesg shows that swap has not been touched free and total are the
same, so this system is not running
On Wed, Apr 20, 2011 at 5:40 PM, Shaun Thomas wrote:
> On 04/20/2011 09:01 AM, Laurent Laborde wrote:
>
>> A review of the V+100 on the excellent anandtech :
>> http://www.anandtech.com/show/4010/kingston-ssdnow-v-plus-100-review
>
> That's horrifying. 4.9MB/s random writes? 19.7MB/s random reads?
On Thu, Apr 21, 2011 at 9:30 AM, Claudio Freire wrote:
> On Thu, Apr 21, 2011 at 4:05 AM, Brendan Jurd wrote:
>>
>> "IMMUTABLE indicates that the function cannot modify the database and
>> always returns the same result when given the same argument values"
>>
>> Emphasis on "always". If the resu
On Thu, Apr 21, 2011 at 4:05 AM, Brendan Jurd wrote:
>
> "IMMUTABLE indicates that the function cannot modify the database and
> always returns the same result when given the same argument values"
>
> Emphasis on "always". If the result of the function, given the same
> argument values, can be di
20 matches
Mail list logo
